Subject: ASCII text message option (option 56)

From: Stuart Cheshire <[email-masked]>
Date: Thu, 29 Jun 2000 14:29:13 -0700

Here at Apple, we're using the DHCP ASCII text message option (option 56) 
to display a "welcome message" when a user first connects to the network 
and acquires a DHCP address (a bit like the "Message Of The Day" when you 
log on to a unix system).

However, in this modern world, some people want more than plain ascii 
text. They want the DHCP server to provide the URL of a web page that the 
client machine should fetch, render, and display in a window.

I see two ways to do this:

1. Define a new DHCP option code for an explicit welcome page URL.

2. Overload the DHCP ASCII text message option, so that if you set the 
text message to be a string of the form:

<URL:http://www.apple.com/welcome.html>

then the client recogises this string as "special" and instead of 
displaying that actual text in the window, it parses the URL and displays 
the web page instead.

Solution 1 is better, but DHCP is running out of option codes, and the 
process of getting new ones allocated can be slow. Apple want to ship 
code that does this, like, yesterday.

Solution 2 is ugly, but easy to do.

Comments?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Jun 2000 14:57:22 -0700

I think it's a brilliant idea, but encourage you to write a draft and
submit it to the WG rather than overloading the text message option.
I'd also suggest in your security section that you say that the web
browser that fetches this page MUST NOT (or at the very least SHOULD
NOT) reveal any information about the user when it fetches the page.
If you write up the draft, I'll second it, and argue for a quick
turnaround.  I can definitely think of applications for this, and if
you implement it, everybody else probably will too!  :')

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 29 Jun 2000 15:04:14 -0700

> log on to a unix system).
...you're actually missing the point of this option a bit, I believe.
[Ralph, please jump in here and correct any misstatements I make!]

...this option is more typically used to convey descriptive error messages
when the server NAKs a client request.  That's not to say that your use is
wrong, but it does reflect my view that DHCP is an underlying service, not a
replacement for MOTD or login banner messages.

...as we go forward, the English-centric nature of many network protocols
will change, and with it, NVT-ASCII for messages will probably change to
accommodate non-English speakers.

...I would oppose the creation of a new option for such a limited purpose as
you are proposing, because I doubt its value in general, and don't believe
the more common clients will handle it in a universally-acceptable way
[having said that, I probably should run out and test my assertion....]

...I also oppose overloading it with a URL through redefinition of the
option:  not because a URL can't be expressed in an NVT-ASCII field, but
because that would require client modifications to utilize effectively.  As
far as Apple shipping clients and servers that make some appropriate use of
the existing option, and even recognize a URL embedded in it, I don't
believe such a use is contrary to the nature of the option -- just don't
expect non-Apple clients to effectively use this mechanism for broadcasting
messages to your client users.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Jun 2000 15:05:41 -0700

> ...I would oppose the creation of a new option for such a limited purpose as

Limited purpose?   What about as the basis for a network sign-on?
The potential here is huge, and IMHO entirely appropriate for DHCP.
Where else would you put this?   Invent an entirely new protocol?

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 29 Jun 2000 15:24:21 -0700

> Where else would you put this?   Invent an entirely new protocol?

...maybe I'm just a doddering old curmudgeon, but I don't see the value
here.  I really don't see the need for using DHCP as a network messaging
system.  As for network sign-on, look at the AAA (Accounting,
Authentication, and Authorization) working group to see how network sign-on
is being approached.

--Barr

---

From: John Schnizlein <[email-masked]>
Date: Thu, 29 Jun 2000 18:45:49 -0400

At 03:24 PM 06/29/2000 -0700, Barr Hibbs wrote:
>... I don't see the value here.  
>I really don't see the need for using DHCP as a network messaging system.
>As for network sign-on, look at the AAA (Accounting, Authentication, 
>and Authorization) working group to see how network sign-on is being 
>approached.

Are you advocating Diameter instead of DHCP to identify and give network
parameters to hosts?  While I agree that convergence between traditionally
separate dial-up and LAN-attached startup parameters is inevitable, it is
not clear that the DCHP WG should just defer to the Diameter WG.
(-: Sorry, I guess it is actually still called the AAA WG.  :-)
I expected more of the time-honored competition between approaches.

John
going back to lurking mode now ..

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Jun 2000 15:54:25 -0700

> here.

I wouldn't describe you as a doddering curmudgeon, but you do indeed
seem to be missing the value of this.

> I really don't see the need for using DHCP as a network messaging

That was probably a poor choice of words.   I'm talking about network
registration.   You walk into a new site, plug in your laptop, and
bang, up comes a registration page where you can identify yourself to
the network and potentially register so that you can get access to
it.   I'm not talking about network signon in the sense of a known
user authenticating him- or herself.

This sort of thing would be a big boon for cable modem and DSL ISPs,
for example, and could also be useful for things like the
much-talked-about but rarely-seen airport 100baseT service.   More to
the point, this is an existing application that people already do -
what Stuart is proposing would merely make telling the end-user how to
register a lot easier - essentially, they would be able to say "just
plug it in and follow the instructions that appear on your screen."
I don't _think_ the AAA people are doing anything like this.

			       _MelloN_