Subject: [Ecrit] Generalizing draft-george-ecrit-lamp-post

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Apr 2010 17:07:29 -0400

It seems like this draft is a little specific to a particular use- 
case.  As several people mentioned in Anaheim, there are lots of  
things around that have numbers on them -- from lamp-posts, mile- 
posts, utility poles, bridges, etc.  If you were going to be  
inclusive, you might include all the QR codes that Google has been  
putting up as well.

So to avoid having to define new CAtypes for every "numbered thing  
that can be a location indicator", could I suggest that we make the  
following generalization?

1. Add a single "place number" ("PLN"?) CAtype with two child nodes:
1.1. A "type" to indicate what type of numbered object is being  
referred to
1.2. The number of the referenced object

2. Add a first-come-first-served registry of type values

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Apr 2010 17:12:04 -0400

We thought of that, although what we considered was a simple attribute for
type and then just leave value as a normal CAtype is defined.  I even said
that in the intro to this version.

The annoyance is that, once again, to do that, you have to create a new
namespace, although I'm getting used to that now (thanks, Martin),
especially when adding a Catype that has subelements or attributes.

Brian

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Apr 2010 17:17:44 -0400

True.  The other annoyance is that you add attributes, sub-elements,  
etc., you have to come up with a binary encoding in order to maintain  
compatibility with DHCP.

Still, it seems wasteful of CAtype space to keep defining new CAtypes  
for every little thing we notice.  Wasn't that kind of the idea with  
INT?

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Apr 2010 17:27:59 -0400

I think there's little advantage of sub-spacing; we have no shortage of CA numbers and each time you do that, you then have to face the issue of whether a new element belongs in one bin or the other.

Henning

On Apr 19, 2010, at 5:07 PM, Richard Barnes wrote:

> It seems like this draft is a little specific to a particular use-case.  As several people mentioned in Anaheim, there are lots of things around that have numbers on them -- from lamp-posts, mile-posts, utility poles, bridges, etc.  If you were going to be inclusive, you might include all the QR codes that Google has been putting up as well.
> 
> So to avoid having to define new CAtypes for every "numbered thing that can be a location indicator", could I suggest that we make the following generalization?
> 
> 1.1. A "type" to indicate what type of numbered object is being referred to
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>