Subject: [dhcwg] New ID for downloading URIs via DHCP

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 Sep 2005 18:38:07 -0500

DHC WG

To let folks know - a new individual submission Internet Draft has been 
announced regarding using DHCP for downloaded (or requesting for, then 
downloading) URIs to a DHC client here:

http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt

with this abstract

    This document defines a new Dynamic Host Configuration Protocol
    (DHC) Option to allow one or more URIs to be transmitted from a
    server to a client within one or more messages, and for one or more
    URIs, each with a unique purpose, to be specifically requested by a
    client of a server.  Included in this Option is a purpose field to
    identify the type of URI being requested by the client, or the type
    of URI in the DHCP message from the server.

Of interest, I hope, to the DHC WG is that this proposed Option requests 
the use of a single DHCP Option to be used for URIs of multiple purposes, 
each identified by a sub-option code called a "purpose". This is done a 
little differently than in RFC 3396 where the sub-options are smaller.  I 
don't believe I violated any length rules of 2131 or 3396, and I believe I 
articulate how to address lengths and concatenation in this document for 
longer URIs, and for how to include more than one URI - each of a different 
purpose - in the same DHCP message, or in the same IP datagram (with the 
same Option value - but different purposes).

The focus of the proposed URIs are primarily surrounding the Geopriv and 
ECRIT WGs

There are 11 URIs currectly defined in this ID (acronym explosion and 
definitions are in the ID):

    Purpose = 1  (Primary PSAP URI)
    Purpose = 2  (Secondary PSAP URI)
    Purpose = 3  (Location By-Reference of Client)
    Purpose = 4  (ESGW URI of Client)
    Purpose = 5  (ESRP URI of Client)
    Purpose = 6  (Organization Providing Location for Client)
    Purpose = 7  (URI of Geocoding/Reverse Geocoding)
    Purpose = 8  (Primary URI of Geo Mapping Service)
    Purpose = 9  (Secondary URI of Geo Mapping Service)
    Purpose = 10 (Primary URI of Civic Mapping Service)
    Purpose = 11 (Secondary URI of Civic Mapping Service)

Others can be added based on consensus discussion of this document

I just spoke with the Ralph Droms, and open discussion of this ID on the 
ECRIT list is fine with him.  The formal syntax and encoding of the option 
proposal is to be discussed on the DHC list for those interested here, but 
the URI meanings don't need to be discussed on this list where emergency 
calling and location conveyance/conversion is of fairly little concern, as 
ECRIT is the primary WG of interest for this effort initially.

That said, newly proposed URIs with completely different purposes can be 
included in this document. I am not suggesting a limitation (other than the 
one byte purpose length field of 255  ;-)

BTW - I have no range set aside for private purposes. Is this needed?

Reviews and comments are appreciated

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Andre Kostur <[email-masked]>
Date: Tue, 13 Sep 2005 07:10:23 -0700

James M. Polk wrote:

> DHC WG
>
> To let folks know - a new individual submission Internet Draft has 
> been announced regarding using DHCP for downloaded (or requesting for, 
> then downloading) URIs to a DHC client here:
>
> Of interest, I hope, to the DHC WG is that this proposed Option 
> requests the use of a single DHCP Option to be used for URIs of 
> multiple purposes, each identified by a sub-option code called a 
> "purpose". This is done a little differently than in RFC 3396 where 
> the sub-options are smaller.  I don't believe I violated any length 
> rules of 2131 or 3396, and I believe I articulate how to address 
> lengths and concatenation in this document for longer URIs, and for 
> how to include more than one URI - each of a different purpose - in 
> the same DHCP message, or in the same IP datagram (with the same 
> Option value - but different purposes).
>
Well.. after a brief read, here's what I can see:

1) Why only 1 byte for the URI purpose?  Do you only ever see the 
possibility of 255 different purposes for an URI?  I would suggest 
extending that to a 2-byte field

2) The way you are currently encoding the data is almost going out of 
its way to break RFC 3396.  Why not either have a 2-byte length value 
for each URI, or define that URIs are 0-terminated and the client can 
break up the full option at the 0s to get the individual sub-options?

3) You don't define how a client "requests" these options.  Do they 
supply 0-length URIs with the purposes that they are interested in?

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Sep 2005 11:00:25 -0500

Andre

Thanks for the quick review - comments below

At 07:10 AM 9/13/2005 -0700, Andre Kostur wrote:
>>don't believe I violated any length rules of 2131 or 3396, and I believe 
>>I articulate how to address lengths and concatenation in this document 
>>for longer URIs, and for how to include more than one URI - each of a 
>>different purpose - in the same DHCP message, or in the same IP datagram 
>>(with the same Option value - but different purposes).
>possibility of 255 different purposes for an URI?

Well, the thought was: how many URIs are foreseen as configuration data 
type URIs? 255 seems like a whole lot (even multiples more than I expect to 
ever be defined). That said, adding another byte to this is very easy. I 
was looking for general feedback if this is a good thing to modify.

>I would suggest extending that to a 2-byte field
>
>2) The way you are currently encoding the data is almost going out of its 
>way to break RFC 3396.

I view this as moving the rules of 2131 and 3396 down one level of 
hierarchy to applying to the sub-options (purposes), instead of to the full 
Options themselves.

3396 states that if the same DHC Option appears more than once in the same 
message, the two values are to be concatenated (to get around the 255 byte 
rule of 2131). This is a limitation that shouldn't be present in the URI 
case, in which concatenation could be across more than one 255 byte 
boundary, yet be one of seveval URIs in the same datagram.

This avoided the extra bytes necessary for what you wrote below: having the 
single DHCP Option value with an overall message length field, then 
sub-option identifiers with their own length fields.

>Why not either have a 2-byte length value for each URI, or define that 
>URIs are 0-terminated and the client can break up the full option at the 
>0s to get the individual sub-options?

I would prefer the former if given the choice

>3) You don't define how a client "requests" these options.

oops - sorry

>Do they supply 0-length URIs with the purposes that they are interested in?

Is this acceptable as the means for requesting which URIs a client wants?

cheers,
James

                                 *******************

---

From: Andre Kostur <[email-masked]>
Date: Tue, 13 Sep 2005 09:30:09 -0700

James M. Polk wrote:

>> its way to break RFC 3396.
>
>
> hierarchy to applying to the sub-options (purposes), instead of to the 
> full Options themselves.
>
> 3396 states that if the same DHC Option appears more than once in the 
> same message, the two values are to be concatenated (to get around the 
> 255 byte rule of 2131). This is a limitation that shouldn't be present 
> in the URI case, in which concatenation could be across more than one 
> 255 byte boundary, yet be one of seveval URIs in the same datagram.
>
> This avoided the extra bytes necessary for what you wrote below: 
> having the single DHCP Option value with an overall message length 
> field, then sub-option identifiers with their own length fields.

However, you are changing 3396 (and 2131) in doing so.  According to 
this draft, it would have 3396 apply to every option except this one.  
As in, every other option is supposed to be concatenated together before 
processing, but this one must not.

> Is this acceptable as the means for requesting which URIs a client wants?
Offhand I don't see why not... but let's see what the other WG members 
have to say about it...

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2005 13:53:50 -0700

On Sep 13, 2005, at 9:30 AM, Andre Kostur wrote:
> However, you are changing 3396 (and 2131) in doing so.  According  
> to this draft, it would have 3396 apply to every option except this  
> one.  As in, every other option is supposed to be concatenated  
> together before processing, but this one must not.

Actually, it's slightly worse than that - it is necessary to  
concatenate, according to this draft, but in order to determine  
whether or not to concatenate, one must look at the purpose field  
within the option.   This is really an unacceptable plan - it  
requires quite a bit of special complexity to support one option.    
Absent some good reason for doing this, which I don't see, we should  
use a method that requires no extra complexity to implement.

What I would suggest is that you just have a length field for the URI  
text, make the other stuff fixed-length (which it is anyway) and  
allow multiple URIs to be represented in a single URI option.   In  
general you don't *want* to send long URIs via DHCP - if the URI is  
that long, it probably isn't going to fit in the DHCP packet.   So it  
would be very good to encourage shorter URIs, and to forbid a URI to  
be longer than 255 bytes.   In general I'm not big on encoding  
limitations into specs, but in this case I think 255 bytes is plenty,  
and it's easy enough to rewrite a URI to be shorter if you need to,  
so I just don't see a lot of value in being flexible about long URIs  
in DHCP packets.   I would make this option a concatenation-requiring  
option (see RFC3396).

So now if you have two URIs in an option, it would likely look like  
this:

[code] [length] [purpose] [uri length] [uri text] [purpose] [uri  
length] [uri text]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Sep 2005 14:07:24 -0700

On Sep 13, 2005, at 9:00 AM, James M. Polk wrote:
>> 2) The way you are currently encoding the data is almost going out  
>> of its way to break RFC 3396.
>
> hierarchy to applying to the sub-options (purposes), instead of to  
> the full Options themselves.
>
> 3396 states that if the same DHC Option appears more than once in  
> the same message, the two values are to be concatenated (to get  
> around the 255 byte rule of 2131). This is a limitation that  
> shouldn't be present in the URI case, in which concatenation could  
> be across more than one 255 byte boundary, yet be one of seveval  
> URIs in the same datagram.
>

Right, but the additional complexity is substantial - it may be easy  
to express as a move down a hierarchy, but in fact it's just going to  
require some additional, fairly hairy special-case code in both the  
client and the server, and this will happen over my dead body.    
Well, anyway, my loudly flaming body.

>> Why not either have a 2-byte length value for each URI, or define  
>> that URIs are 0-terminated and the client can break up the full  
>> option at the 0s to get the individual sub-options?

I agree with you that using a NUL-terminated string is a mistake.   I  
agree in principle also that using a two-byte length makes some  
sense.   However, if you use a two-byte length, you're placing an  
additional implementation burden on clients and servers, although the  
burden is significantly smaller than the burden imposed by your  
current proposal.   This is because clients and servers currently  
support length-specified strings where the length is specified in a  
single byte.   So I would argue against using two bytes.   Is there  
some reason why you think URIs longer than 255 bytes are really crucial?

Another reason that I say that you should really constrain the length  
is that in practice what's going to happen if you don't is that  
someone is going to use a really long URI with a bunch of HTML forms  
junk in it, because that's easier than doing a custom HTML script,  
and then this poor bastard is going to wonder why the URI option  
isn't getting sent, and call your support guys or ours on the phone  
and demand answers.   The answer will be "your URI won't fit in the  
packet - use a shorter one."   But IMHO it's better to force that  
constraint on them then to have to figure out precisely what's going  
wrong at support call time - it could actually take a bit of thinking  
for the support person to make the right connection, because these  
things *really* aren't obvious when seen from that perspective.

Now, in DHCPv6-land, you *should* use two-byte lengths, because in  
DHCPv6-land that's what everything uses.   But you should still tell  
the user to keep URIs short.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 18:31:40 -0500

Ted

Thanks for the (blunt) comments...

several comments below, but first:

OK, ok - I give.... "uncle"

I'll fix the doc to be more in line with 3396

>[code] [length] [purpose] [uri length] [uri text] [purpose] [uri

but have a few comments about what else you said that might impact this 
pseudo-format above

>requires quite a bit of special complexity to support one option.

see above

>use a method that requires no extra complexity to implement.

ok

>allow multiple URIs to be represented in a single URI option.

ok

>In
>that long, it probably isn't going to fit in the DHCP packet.

255 (max for a single option) seems like a bit of a different than 576 
(DHCP's message maximum) - unless Ive gotten the numbers revered

>So it
>would be very good to encourage shorter URIs,

I can state this

>and to forbid a URI to
>be longer than 255 bytes.

This is a bit more difficult as we cannot foresee the implementation usage 
that far into the future, can we?

>  In general I'm not big on encoding

How about a "...SHOULD NOT have URIs longer than 255..."

>in DHCP packets.

OK, but how about a compromise between what you have here, and what I had 
originally, like this:

Go with this pseudo-format
[code] [length] [purpose] [uri length] [uri text] [purpose] [uri length] 
[uri text] [etc]

Say: "SHOULD NOT have URIs longer than 255"

But: you MAY have a longer URI with the following (rough) rules:

#1 - (all of 3396 applies)
#2 - because of the difference between 255 and 576, allow more that one 
"purpose" group (meaning [purpose] [uri length] [uri text] ) in the same 
overall message, but this falls under the concatenation-required before 
processing rule of 3396
#3 - allow more URIs in their own "purpose" group ( [purpose] [uri length] 
[uri text]   ) fill up the remaining bytes left in the message, not to 
exceed 2131 limits

This will allow a URI to be up to 576 minus required bytes (which is still 
very large) while overcoming the 255 limit (which some have foreseen as 
"pushing it" in the future), and allowing more than one URI in the same 
message only if there is room.

For example:
[code] [length] [purpose=1] [200] [uri text] [purpose=1] [125] [uri text] 
[purpose=2] [180] [uri text] [purpose=7] [30] [uri text]

This allows two URI fields (one of 200 bytes and one of 125 bytes) to be 
concatenated as one 325 byte URI (the primary PSAP URI), one 180 byte URI 
(the secondary PSAP) and one Geocoding URI of 30 bytes to be in the same 
DHCP message to the client.

This makes 535 bytes of URIs plus 6 more bytes of overhead bytes = 541 bytes

Is this concept acceptable?

>  I would make this option a concatenation-requiring
>option (see RFC3396).
>

cheers,
James

                                 *******************