- From: Rob Bull <bull@crxnet.com>
- Date: Fri, 20 Oct 2000 18:34:44 +0000 (GMT)
- To: Sebastian Hammer <quinn@indexdata.dk>
- cc: Ray Denenberg <rden@loc.gov>, www-zig@w3.org
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