Re: Remaining open issues for RFC-2401bis

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

> At 11:36 AM -0800 3/24/04, Mohan Parthasarathy wrote:
> >  >
> >>
> >>  >>>>> "VPNC" == VPNC  <Paul> writes:
> >>      VPNC> No, we don't. We have ways of encoding the display name and
> >>      VPNC> the coments, but *not* the address itself (called the
> >>      VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this.
> >>
> >>    Ah, good point.
> >>
> >>      >> 2) we could agree to permit UTF-8 in RFC822_ADDR.
> >>
> >>      VPNC> Doing so and hoping that the Applications Area Directors don't
> >>      VPNC> barf is like
> >>
> >>    Fine. Point made.
> >>    So, we need an identifier that can carry UTF-8, is known to carry
> >>  UTF-8, and isn't ID_KEY_ID.
> >>
> >I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an
> >opaque way. I think this is what Paul Koning mentioned in an earlier mail.
> >
> 
> For the reasons cited earlier, I think it is a bad idea to carry 
> structured data like UTF-8 in what is described as an opaque octet 
> string. there is no reason to assume that there will be management 
> interfaces to facilitate entry of the data in a compatible fashion, 
> even without the encoding options that Paul has pointed out.
> 
ID_KEY_ID is defined as an opaque octet stream and UTF-8 can be
carried as an opque stream of bytes where the two ends do a "memcmp" of the
opaque byte stream to match on the ID contents. Why is this not possible ?
As i mentioned in the other mail, this content may be dynamically generated. 
Perhaps we need a different ID to carry structured data like UTF8 that will be
created through mangement interfaces. At least, that is what i understood from
the emails on this topic.

-mohan


> Steve