Subject: RE: the 9 step program

From: <[email-masked]>
Date: Thu, 27 May 2004 10:32:59 +0300

Hi Iljitsch,

> > Could you clarify what you mean by user below?  Is it what is
> > exposed to the application or something else.  User can imply
> > human user, but I am not so sure about your meaning.
> 
> Yes, I mean the human user. I suppose there are some applications where 
> there are no user-visible names or addresses, but usually there is: the 
> FQDN part of an URL, the FQDN part of an email address, the FQDN used 
> in telnet/ftp/ssh, various server names/addresses... The interesting 
> part is that this is usually a character string that can either be a 
> simple hostname, an FQDN, a literal IPv4 address or a literal IPv6 
> address.

OK, so your point was:

> 1. The name or address value as it appears to the user. (FQDN, textual 
> representation of an IPv4 or IPv6 address, port number usually 
> implied.)

WRT to Multi6, I think that this should be a non-goal - you seem to
be pre-supposing that the user may see the name.  I would imagine
we have many possiblities, not restricted to:

1) URI, FQDN, etc. <-> multi6 name <-> IP address used (shim layer)
2) Multi6 address is in the form of some URI, FQDN, etc. (application level address)
3) Multi6 address is in the form of an IP address (something like HIP)

I'm not sure worry about this point is useful.

thanks,
John

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 May 2004 10:28:40 +0200

>> representation of an IPv4 or IPv6 address, port number usually

This isn't really a point... I was just listing the places where 
names/addresses are used in some way in IP communication. This is one 
of them.

> be pre-supposing that the user may see the name.

Someone has to see something to begin with. After that there can be 
invisible referrals.

> I would imagine we have many possiblities, not restricted to:

> 3) Multi6 address is in the form of an IP address (something like HIP)

So how does 1 compare to 3? Having a special multi6 name (apart from 
the FQDN) that isn't in the form of an IPv6 address seems like asking 
for trouble to me.

I think the "9 step program" illuminates the difference between 2 and 3:

     Regular IP       multi6=fqdn   multi6=address
1.  s=0, d=FQDNX     unchanged     unchanged
2.   | s=A, d=X      changes req.  unchanged
3.   | s=A, d=X      depends       changes req.
4.   | s=A, d=X      depends       depends
--- i --- n ---   --- t --- r --- a --- n --- s --- i --- t ---
5.   | s=A, d=X      depends       depends
6.   | s=A, d=X      depends       depends
7.   | s=A, d=X      depends       changes req.
8.   | s=A, d=X      changes req.  unchanged
9.  s=FQDNA, d=X     unchanged     unchanged    <-- (firewalling issues)

Referrals:           changes req.  depends

> I'm not sure worry about this point is useful.

I'm not worried.  :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 May 2004 15:45:21 +0200

Iljitsch van Beijnum wrote:
> names/addresses are used in some way in IP communication. This is one of 
> them.
> 
> So how does 1 compare to 3? Having a special multi6 name (apart from the 
> FQDN) that isn't in the form of an IPv6 address seems like asking for 
> trouble to me.
> 

Two other comments on this.

1. There will be many cases where there is no user (at least at run
time) to admire the FQDN on her screen. FQDNs will for example be buried
in automatically generated XML documents that are used to trigger network
access in a Web Services environment.

2. FQDNs are now internationalized, so they cannot be assumed to be
ASCII strings at all times - in some contexts they will be Unicode.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 May 2004 16:52:13 +0200

> access in a Web Services environment.

Ok, in v2 I'll make this "the FQDN or textual representation which is 
presented to the user if applicable".

> ASCII strings at all times - in some contexts they will be Unicode.

In other words, the address is transformed from Unicode to ASCII and/or 
the other way around at some point. I think we can safely ignore this 
for the purposes of multihoming, at least until we've reached the 
lowest level of detail.