Jay Martin wrote:
>After reviewing Bob Herriot's set of example encodings (nice job, Bob),
>I feel I understand the impact of the proposed "tweak", yet I still don't
>come away with a strong feeling that such a change is really needed.
I would concur. Bob asked for "strong arguments against" it and I
really don't have any. I don't think it is that hard to implement.
It just adds some additional error conditions that need to be clearly
documented, implemented, and tested. Just one more straw for the
camel's back...
(Did anyone else have that game years ago??? A camel who was split
in the middle with an elastic band connecting front with back half.
You add "straws" to the basket on his back, whoever adds "the straw
that breaks the camel's back" loses... They sit out the remainder.)
>I realize that some folks (such as Steve Zilles and Roger deBry) have
>been lobbying for a Tag-Length-Value (TLV) approach for a while now,
AKA "triplets" That was actually far more "binary" than our current
approach. It could, for example, eliminate attribute names (the
'tag' becomes the name).
>but the group had previously said NO to this approach (right?). Yet,
I thought so.
>If the desire is to have a TLV mechanism, then why are we reinventing
>what has already been accomplished via ASN.1/BER? (This is precisely
ASN.1/BER is a very complex encoding mechanism for TLV. I don't
believe that a TLV or triplet approach necesitates ASN.1/BER or even
that that would be the best choice.
>The greater good of IPP rests with pervasive deployment of a reasonable
>set of standard features. Anything that gets in the way of this simple
I agree. For my part, it is an unfortunate reality that schedule is
becoming a driving force. :(
[re. the HP and MS stand]
For the summary of MY position re. 'types' aka 'tags', see my first
paragraph above.
sdb
| Sylvan Butler | sbutler at boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |