Subject: Re: non-standard IPv4 form support in getaddrinfo()

From: Tim Hartrick <[email-masked]>
Date: Tue, 8 Feb 2000 10:31:04 -0800 (PST)

Jim,

> IPv6 numeric address" which "is defined in jinmei's draft" 
> 
> That to me means your saying inet_pton must be able to accept:
> 
> A)  4ffe::12 (which it does today)
>       and
> B)   4ffe::12|323 (where | is a delimeter to define the scope_id 323
>                  or however we all agree to define this via jinmei's
>                  work)
> 
> If we support "B" above its a change to inet_pton and why I said what I
> did.  
> 

So are you saying that if an implementation chooses to enhance the inet_pton
so that is can parse over/around the scope_id in example B) that it will
not be in compliance with XNS?

I can understand not requiring inet_pton to be able to parse B).  But for-
bidding it from being able to parse B) doesn't seem right.

tim 
--------------------------------------------------------------------
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: Tue, 08 Feb 2000 15:21:09 -0500

Tim,

>bidding it from being able to parse B) doesn't seem right.

I agree.  What I am saying is this.

We should not change the definition in rfc2553 or xns of inet_pton
except to define more clearly with examples what "standard" means.
If implementors want to create and added value inet_pton thats their
choice it is not the business of the standard pro or con and will remain
silent on the topic.

regards,
/jim