Re: eSpec-q ASN.1 questions

Sebastian,

that was my original reasoning for raising this - and I'm happy that the 
definition be changed through a defect process.

Ray - if you are able to confirm that there is no specific reason for this
being replicated here, you can also have my vote for removing it and
adding it to the IMPORT list.

Rob


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 Rob Bull    bull@crxnet.com         Crossnet Systems Limited
 tel +44 (0) 1635 522912             Unit 41 Bone Lane, Newbury 
 fax +44 (0) 1635 522913             Berkshire, RG14 5SH, United Kingdom
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


On Sat, 21 Oct 2000, Sebastian Hammer wrote:

> At 16:01 20-10-00 +0000, Rob Bull wrote:
> 
> > > Was there a reason to explicitly define AttributesPlusTerm instead of 
> > Importing
> > > it? I thought there was, but I can't reconstruct it.  It could have been
> > > Imported. Does it matter? Do you want a defect report generated?
> >... its just that I thought we generally tried to avoid duplication of ASN
> >where possible. We're happy to leave it is as it is - its probably less
> >hassle than going through the defect procedure.
> 
> There's no interoperability issue, but for the convenience of people using 
> ASN.1 compilers, it seems to me it would be preferable to avoid this type 
> of redundancy. So I guess I would cast my vote for fixing thew problem, if 
> indeed Attributesplusterm has been wrongfully re-defined.
> 
> --Sebastian
> --
> Sebastian Hammer        <quinn@indexdata.dk>            Index Data ApS
> Ph.: +45 3341 0100    <http://www.indexdata.dk>    Fax: +45 3341 0101
> 
> 

Received on Friday, 20 October 2000 13:37:08 UTC