Xml Mailing List: RE: Re: Vendor element

[Mark Jones (mjones]

Hi Dave,

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

Ditto. Been trying to get my head around the MIPv4 KDC.

> I agree.  A child dictionary would be better.
>

Done and in CVS.  As the Vendor entries will be significant, this is
probably a good candidate for being a separate XML file.

> Ok.  First of all, let's call it vendor-alias.

I like it. Definitely better than label.

> 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.

But it was being used to lookup a Vendor (at least in my code). I parsed the
AVP element and if it was present, lookup the vendor-alias ("Sun") in my
Vendor element map to find the vendor-id ("42").

So I think the ambiguity would arise when the dictionary contains 15 Vendor
element entries for Ericsson* and an AVP entry is added with a vendor-alias
which refers to the wrong Vendor element.

> 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.
>

Agreed. Definitely more readable too but I still think we need to keep to
something that IANA controls to avoid ambiguity.

> 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 . . .
>

How about simply using the Enterprise name from the IANA list?

        <avp name="Ping-Timestamp-Secs" code="1"
                        vendor-name="Sun Microsystems" mandatory="mustnot">
                <type type-name="Unsigned32"/>
      </avp>

Probably not the preferred solution of "Alice-Salomon-Fachhochschule fur
Sozialarbeit und Sozialpadagogik Berlin" but how many Diameter VSAs are they
likely to come up with? ;)

> > 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.

Done and in CVS.

Regards,
       Mark