Subject: Re: rfc2553bis Update overview of assumptions, goals, etc.

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 03 Feb 2000 02:26:10 +0900

Hi,

>>>>> On Thu, 27 Jan 2000 13:04:28 -0500, 
>>>>> Jim Bound <[email-masked]> said:

> It is time to update because of the scope_id issues RFC 2553, the work will 
> be rfc2553bis.  Before I start changing text, editing etc. I would like to 
> be clear on the input and issues we need to resolve in the spec.  First I 
> present some assumptions, then the changes in general that must be made per 
> all the input.  Once we get that level of understanding I can then start
> changing the spec.  All of this needs some discussion.  Lastly I present
> the reviewers of this update that are needed to achieve consensus on
> this spec.

> IMPORTANT: The reason we are updating the spec is because of the
> scope_id issue.  This is not a free-for-all to put everything people
> want in the API, we have shipping products now, existing users, and
> binary compatibility is imperative for this API and I would also add
> source portability.  

> Assumptions:

> Not being done in rfc2553bis at this time I assume these will be info
> rfcs?: 
> A:  A paper will be written for scope_ids (carl williams)
> B:  A paper on concatenating scope_ids and addresses (JINMEI Tatuya)
> C:  A paper on literal IPv6 addresses with port numbers (TBD)         
> D:  A paper on multihoming API issues (TBD)
> E:  Others ?????????????????

Thanks for referring our draft. We're now locally discussing the draft
(B) and will soon be revised the draft including

- more text about a background of the scope issues
- a (proposed) specific format of scoped addresses with agreement
  among early implementors

Regards.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Wed, 02 Feb 2000 17:44:17 -0500

Hi JINMEI,

>- a (proposed) specific format of scoped addresses with agreement

This is great.

I think we need two things from you.  1 is a draft for sure and I think
you should go for RFC status.  I think informational this also gives you
credit for the idea.  But also we need something for 2553bis we can get
done quickly.  Anyway think about my input and let us know.

thanks
/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 04 Feb 2000 02:14:29 +0900

>>>>> On Wed, 02 Feb 2000 17:44:17 -0500, 

> credit for the idea.

Okay, thanks.

> But also we need something for 2553bis we can get

Hmm, if you mean some definitions (e.g. macro names of new flags) that
are related to 2553bis, I'll try to clarify them ASAP, and will send
the result to this list before revising our draft.

Regards.

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Thu, 03 Feb 2000 20:31:24 -0500

>the result to this list before revising our draft.

Whoops.  If you want to add macros and other needs for parsing thats
cool.  But I was thinking the text we need to put in rfc2553bis that may
be needed so an api developer has a clue.

thx
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 03 Feb 2000 20:43:28 -0500 (EST)

thx
/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 04 Feb 2000 23:52:36 +0900

>>>>> On Thu, 03 Feb 2000 20:43:28 -0500 (EST), 

> be needed so an api developer has a clue.

I see, thanks for the clarification. I'll discuss it in the KAME team
and send some text to this list. It would contain an overview of the
new address format and relationship between textual addresses and
values in the sin6_scope_id field.

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Fri, 04 Feb 2000 11:36:49 -0500

thank you........any help is going to be highly appreciated by the
authors...

/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 22 Feb 2000 02:44:47 +0900

>>>>> On Fri, 04 Feb 2000 23:52:36 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> values in the sin6_scope_id field.

Sorry for the delay. Howe about the following text? It would be added
to Section 6.4 and 6.5 of RFC2553. I'll attach the text itself with
some original parts of the draft to supplement the context.

I didn't mention the precise format of the extended format of IPv6
scoped addresses. Instead, I just referred to our draft in order to
avoid duplicated description. However, if it doesn't make sense, I'll
revise the text with the specific format.

The text might still be unclear. If so, please let me know. I'll try
to make the text clearer in response to comments.

As for the precise format, we've discussed it with Brian (Zill@MSR),
Rich (Draves@MSR), Francis (Dupont@INRIA), and some KAME guys, and
almost agreed on the following format:
<scoped_address>%<scope_id>
that is,
- the delimiter character is `%'
- the scope_id part is placed after the address with the delimiter.

I'm going to revise our draft with this format and will soon post it
to the list.

Thanks.

					JINMEI, Tatuya

6.4 Protocol-Independent Nodename and Service Name Translation

page 27:
   The nodename and servname arguments are pointers to null-terminated
   strings or NULL.  One or both of these two arguments must be a non-
   NULL pointer.  In the normal client scenario, both the nodename and
   servname are specified.  In the normal server scenario, only the
   servname is specified.  A non-NULL nodename string can be either a
   node name or a numeric host address string (i.e., a dotted-decimal
   IPv4 address or an IPv6 hex address,
[addition:]
   which includes an extended address format for a scoped IPv6
   address[Refer to the scopedaddr-format draft]).
...

page 28, 2nd paragraph:
   socket() function.  In each addrinfo structure the ai_addr member
   points to a filled-in socket address structure whose length is
   specified by the ai_addrlen member.

[addition:]
   If the nodename is a textual IPv6 scoped address with a scope
   identifier, getaddrinfo() sets the appropriate numeric number
   for the scope identifer to the sin6_scope_id field of each returned
   sockaddr_in6 structure. For a zero or positive numeric scope
   identifier, getaddrinfo() simply copies the value to the
   sin6_scope_id field, and lets the kernel validate the value. If the
   scope identifier is given as a string (e.g. an interface name),
   getaddrinfo() first translates it into an according numeric number,
   and then sets the number to the sin6_scope_id field. The mapping
   between the string to the numeric number is implementation dependent.
   Getaddrinfo() returns the EAI_NONAME error when the translation
   fails. It also returns the same error code if the scope identifier
   is a negative number.

   If the AI_PASSIVE bit is set in the ai_flags member of the hints
   structure, then the caller plans to use the returned socket address
   ...

6.5 Socket Address Structure to Nodename and Service Name
...

   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
   located in the DNS, the numeric form of the host's address is returned
   instead of its name (e.g., by calling inet_ntop() instead of
   getipnodebyaddr()).
[addition:]
   Moreover, if sa points to a sockaddr_in6 structure for an IPv6
   scoped address and the sin6_scope_id field of the structure has
   a non-zero value, the returned numeric form should be in the
   extended format, that is, the address is followed by a scope
   identifier according to the value of the sin6_scope_id field with
   the delimiter character. The scope identifier is either the numeric
   number of the sin6_scope_id field or an implementation specific
   string (e.g. an interface name) of the sin6_scope_id field. If sa
   points to a sockaddr_in6 structure for an IPv6 global address with
   a non-zero value of the sin6_scope_id field, getnameinfo() simply
   ignores the sin6_scope_id field and just returns the numeric form
   of the global address.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------