Subject: draft-ietf-sip-dhcp-02.txt

From: Ralph Droms <[email-masked]>
Date: Fri, 19 Jan 2001 17:43:08 -0500

The SIP WG has asked the DHC WG for input on "DHCP Option for SIP Servers", 
<draft-ietf-sip-dhcp-02.txt>.  Please review this draft (it's less than 
four pages!) and post any comments to this mailing list before 1/24 (next 
Wednesday).  Thanks...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Jan 2001 10:42:50 -0700

My only comment on the draft is that given the frequency with which
some implementors misread drafts, it would be good to really stress
that the option is in DNS encoding, not a text string (if that is the
intent).

   This option specifies the DNS [6] string that is passed to the
   client. This string SHOULD be the domain name of the SIP server
   (rather than a textual representation of the network address). The
   code for this option is TBD. The length of the DNS name string is
   specified in `Len'. The maximum length of this string is 255 octets
   and minimum length is 1 octet. For example, a value may be

Hm.   Actually, now that I think about it, it doesn't say what I
thought it said.   So this is unclear - if it's supposed to be a text
string, it should say so explicitly, maybe like this:

The domain name SHOULD be encoded as a printable representation of a
fully-qualified domain name, as described in [6].   The name MUST
NOT include a NUL termination byte at the end of the string.

BTW, I would actually suggest encoding the string in DNS wire format
rather than in presentation format (a text string), because this is
more flexible - it may be difficult to losslessly represent
internationalized domain names as plain ASCII strings.  This is the
approach that Bernard Aboba took with the new domain name search list
option, so new clients will have to be prepared to decode this format
anyway.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Mon, 22 Jan 2001 11:18:45 -0500

Ted,

> that the option is in DNS encoding, not a text string (if that is the

What are the encodings of other DNS "strings" in other DHCP options?
Seems like one would want to start there, for compatability with
deployed servers.  Are any of the existing options using DNS
"on-the-wire" encoding, for example?

Thomas

---

From: Dale Worley <[email-masked]>
Date: Mon, 22 Jan 2001 12:08:06 -0500

From: Ted Lemon <[email-masked]>

   BTW, I would actually suggest encoding the string in DNS wire format
   rather than in presentation format (a text string), because this is
   more flexible - it may be difficult to losslessly represent
   internationalized domain names as plain ASCII strings.

You *know* that the DNS wire format is future-proof, and it will
always be able to represent any valid domain name, no matter in what
direction DNS evolves.  If you try to represent in ASCII, or any other
text format, you will have to adjust the spec every time the space of
domain names changes.

Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <[email-masked]>
Virata Corp.	  Applications Infrastructure   http://emweb.com

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Jan 2001 15:43:43 -0600

> "on-the-wire" encoding, for example?

The fqdn option does.  The proposed domain name search list option
does.  I don't see that "compatibility" in this case is particularly
valuable - what makes you say that it is?

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Mon, 29 Jan 2001 12:15:31 -0500

> valuable - what makes you say that it is?

If I was wearing a "sip srv" hat, my assumption would be that I would
want this new option useable by existing deployed DHCP servers with
little or no hassle. I.e., if I encoded the option in a way that
required deployment of new servers, that would be a fairly big
negative.  Immediate deployability has been a factor in deciding the
exact format of other options discussed in the last couple of years.

Wearing a "good for dhcp" hat, I'd want the format to be be as future
proof as possible (e.g., perhaps same as the DNS on-the-wire
format). I'd also want to be sure that the description of the actual
bytes in the option are clearly enough defined that there won't be any
interoperability problems once it gets implemented/deployed.

Right now, IMO the option isn't specified clearly enough to avoid
interoperability problems. I think the WG could really help here by
saying what it thinks should be done.

BTW, this option has been in the works for some time, and this is the
last remaining issue. So if the WG could come to closure quickly and
make a recommendation, this (and its companion document
draft-ietf-sip-srv-01.txt) could be approved and sent to the RFC
editor.

Thanks,
Thomas