One tiny suggestion that has nothing to do with the merits of needing these
two types in the first place, but only with the actual names? I've got a
generic aversion to names that assume by their nature that there will never
be any future expansions, so rather than "BigText" and "BigOctetString", how
about "Text65K" and "OctetString65K"?
This would preclude a need for things like "BiggerText" and
"StillEvenMoreUnbelievablyHugeOctetString" in future expansions when it is
found that there's a need for something even larger, probably more than
once. With my suggested pattern there would just be "Text265K", "Text1Meg",
etc., for as many expansions as occur, without breaking the pattern.
Besides, "Text65K" and "OctetString65K" are more descriptive of the actual
size limits. They also allow recognition of the underlying type from the
prefix, without finishing the parse to see what the limit is, in case a
given implementation doesn't care for some reason.
Maybe it's just having lived through too many instances of "this is big
enough for all time", but that's my immediate impression anyway. Thanks for
"listening".
-- Mike Bartman
> -----Original Message-----
> From: pmoore@netreon.com [mailto:pmoore@netreon.com]
> Sent: Monday, January 29, 2001 12:42 PM
> To: ipp@pwg.org
> Cc: ifx@pwg.org
> Subject: IPP> New data types
>
>
>
>
> Fellow IPPers,
>
> In the IPP Fax meeting in Maui (1/26/01) we decided that we
> needed two new data
> types to deal with large lumps of data.
>
> BigText. This is just like Text except that it is up to 65535
> bytes long
> BigOctetString. This is just like OctetString except it is up
> to 65535 bytes
> long.
>
> BigText is used for vcard representation of users. [Note to
> ifx attendees - this
> does need to be text since it contains localized human
> readable data - my
> mistake].
>
> BigOctetString is used for CONNEG data. We are alos
> considering using it for
> carrying digital certificates.
>
> We considered several alternatives but this seemed the
> cleanest solution.
>
> Can I therefore ask that this be a topic for your next
> meeting so that you can
> bless this change (or not of course!)
>
> THnaks
>
> Paul Moore
> IPP Fax Chair
>
>
This archive was generated by hypermail 2b29 : Mon Jan 29 2001 - 14:45:42 EST