Xml Mailing List: Re: Vendor element

[David Frascone (dave]

Sorry it took me so long to respond.  Been chasing some nasty bugs.


On Wed, Sep 12, 2001 at 02:51:36PM -0400, Mark Jones wrote:
> Dave, Erik,
> 
> First off, I think that vendor should be a child element of dictionary
> rather than a child element of base and application. Vendors can have AVPs
> and commands across multiple applications so I don't see why these vendor
> elements would be defined under individual applications. Are there any
> benefits to the current layout that I'm missing?

I agree.  A child dictionary would be better.

> 
> I'd also like to suggest some vendor attribute renaming for the sake of
> clarity. The base protocol RFC uses the term 'vendor-id' to describe the SMI
> Private Enterprise Code whereas the current DTD uses it as a shorthand for
> the vendor name (or vendor label). So I'd like to see 'vendor-code' renamed
> as 'vendor-id'. This leaves us looking for a new name for the current
> 'vendor-id' attribute (see below).

Agreed.

> I understand the motivation for the 'vendor-id' (hereafter referred to as
> the vendor label) as a shortform of the vendor name but am concerned that we
> may be creating interop issues since these vendor labels are not issued by
> IANA. Some vendors, for example Ericsson, possess several vendor ids and
> each group will probably grab the 'Ericsson' label. To guarantee
> interopability, I think we should derive the vendor definition from
> 'ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers'. So I
> suggest we either require that the vendor labels are assigned by IANA or
> drop them altogether and use the SMI Private Enterprise Code to
> cross-reference AVPs and Commands to their vendor element.

Ok.  First of all, let's call it vendor-alias.  I was only using them in
the dictionary to make it a little easier to read.  I don't think it adds
any ambiguity, since the alias would never be transmitted or used to look up
a vendor.  We could just use the vendor-id (numeric) as the index, but it
is a little easier to modify by hand if the key is an alpha.

So, I would prefer one of the following two suggestions:
        Either keep the old vendor-id concept, rename it to
        vendor-alias, and use it as a key within the dictionary,
        or, trash it all together, and use the old vendor-code (now
        vendor-id) as the key.

I would much prefer the former, but if you think it will cause too much
confusion . . . 

> Dave, I think we also concluded that the constrained and vendor-bit
> attributes on the AVP are redundant. They are still in the DTD but I'm
> ignoring their value for now. Can I remove them and send you the diffs?

Yes.