Brian used the vertical bar (|), but that would lead to escaping problems if you decided that types could use that character. It's possible that invalid Unicode (0xff) could be used, or a reserved character (NUL, U+0000). Ultimately, it doesn't matter.
I'm against any attempt to attach semantics to these - which adding specific CAtypes would necessitate - that would defeat the purpose of the proposal.
--Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Tuesday, 20 April 2010 7:20 AM
> To: Richard Barnes; Brian Rosen
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] Binary encoding of INT?
>
> At 04:09 PM 4/19/2010, Richard Barnes wrote:
> >Looking at draft-rosen-geopriv-pidf-interior, it doesn't look to me as
> >if it defines how you encode an INT element into a binary CAtype for
> >DHCP. Seems like this would be a good thing to have in order to
> >maintain parity between the binary and XML forms?
>
> I've been saying all along in order to have this parity work, the new
> INT fields will have to be uniquely numbered.
>
> In other words, instead of ONE CAtype=40 for all INT elements (with
> additive text identifying the element), you need to have separate
> numbers, which for TLVs, translate into separate type values --
> otherwise, this doesn't translate into binary at all.
>
> James
>
> >_______________________________________________
> >Geopriv mailing list
> >Geopriv@ietf.org
> >https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
