From owner-IPv6-jp@jp.freebsd.org  Fri Jan 14 02:22:29 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id CAA57134;
	Fri, 14 Jan 2000 02:22:29 +0900 (JST)
	(envelope-from owner-IPv6-jp@jp.FreeBSD.org)
Received: from cerberus.nemoto.ecei.tohoku.ac.jp (root@cerberus.nemoto.ecei.tohoku.ac.jp [130.34.199.67])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id CAA57129
	for <IPv6-jp@jp.freebsd.org>; Fri, 14 Jan 2000 02:22:28 +0900 (JST)
	(envelope-from yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp)
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id CAA07010;
	Fri, 14 Jan 2000 02:22:28 +0900
To: IPv6-jp@jp.freebsd.org, itojun@iijlab.net
Cc: shin@nd.net.fujitsu.co.jp, simokawa@sat.t.u-tokyo.ac.jp
From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=)
 <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <13986.947780036@coconut.itojun.org>
References: <20000114011219B.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
	<13986.947780036@coconut.itojun.org>
X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1
 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?=
X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Message-Id: <20000114022228S.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date: Fri, 14 Jan 2000 02:22:28 +0900
X-Dispatcher: imput version 990905(IM130)
Lines: 34
Reply-To: IPv6-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+990727
X-Sequence: IPv6-jp 483
Subject: [IPv6-jp 483] Re: rresvport_af 
Errors-To: owner-IPv6-jp@jp.freebsd.org
Sender: owner-IPv6-jp@jp.freebsd.org
X-Originator: yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp

In article <13986.947780036@coconut.itojun.org> (at Fri, 14 Jan 2000 01:13:56 +0900), itojun@iijlab.net says:

> >($B5!G=LL$G(B)$BH?BP$7$F$$$k?M$O$$$J$+$C$?$h$&$J5$$,$7$^$9!#(B
> >$B$G!"F1MM$N4X?t$r(B Linux glibc $B8~$1$K<BAu$7!"(B
> >iruserok_sa $B$H$$$&L>A0$OJQ$J5$$,$7$F(B ruserok_sa $B$H$7$F$_$^$7$?!#(B
> >$B8=;~E@$G$O;~4|>0Aa(B? $B$^$?!"(Biruserok_sa $B$K$"$o$;$?J}$,$$$$$G$7$g$&$+(B?
> 
> 	This does not make sense to me (as noted previously on ipngwg).
> 	ruserok() is already there and ruserok() is totally af independent.

ruserok() is protocol-independent human-readable interface and
ruserok_sa() will be protocol-independent machine-readable interface.

ruserok_sa() over addresses returned from getaddrinfo() is the function of 
ruserok().  If you know the remote machine's address in machine 
readable format only,  it is natural to use ruserok_sa().
If we don't have ruserok_sa(), we may want to do getnameinfo(), 
but this solution sounds strange because the lower address description 
goes up to the higher human-readable layer.


If you don't agree,  you don't need iruserok_sa() because
iruserok_sa and ruserok_sa are the same.

If you agree, the name of the function is important for portability
and it is worth discussing.

And, if you think the iruserok_sa() / ruserok_sa() is very internal,
you should declare it as a static function.

-- 
Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
