RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt

["Skovgaard, Erik" <Erik.Skovgaard@icn.siemens.com>]

Kurt,

Agreed.  Perhaps there should also be an attribute for the text form?  Or
the attribute could be a compound form, for instance:
vendorName=2.16.840.1.113999{SuperDirectory Corp.}

That would address both the display and the machine use.

Cheers,               ....Erik.


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, October 26, 2000 16:44
To: Skovgaard, Erik
Cc: 'Mark Meredith'; ietf-ldapext@netscape.com
Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt


I believe a directory string would be more appropriate than
an object identifier for display purposes.

At 04:28 PM 10/26/00 -0700, Skovgaard, Erik wrote:
>Mark,
> 
>Any vendor that plays in the Directory space should have an OID assigned to
>them, so that should not be an issue.
> 
>If a vendor has OEM'd the software and added features, I think the OID
>should be that of the value-added vendor.  If no features have been added,
I
>would think the vendor can choose to use either the original developer's
OID
>or the vendor's own OID.  I did consider allowing multiple values for this
>attribute (e.g. original vendor, value-added1, value-added2), but this may
>not be palatable by the marketing people.
> 
>The OID would, IMHO be more specific than a text-based vendor name.
> 
>Cheers,                                  ....Erik.
> 
>
>-----Original Message-----
>From: Mark Meredith [mailto:MMEREDIT@novell.com]
>Sent: Thursday, October 26, 2000 12:15
>To: Skovgaard, Erik; Kurt@OpenLDAP.org
>Cc: ietf-ldapext@netscape.com
>Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt
>
>
>So do you mean that each vendor would have an OID assigned to them or in
the
>case of OEM they would use the original OID?
> 
>Can you explain how this would work in more detail?
> 
>-Mark
> 
> 
>Mark Meredith
>Software Engineer
>Novell Inc
>1800 Novell Place, Provo UT 84606
>mark_meredith@novell.com <mailto:mark_meredith@novell.com> 
>801-861-2645
> 
>Novell, Inc., the leading provider of Net service software
>www.novell.com <http://www.novell.com> 
> 
>---------------------
>A boat in the harbor is safe, 
>but that is not what boats are for.
>--John A. Shed
>---------------------
>
>>>> "Skovgaard, Erik" <Erik.Skovgaard@icn.siemens.com> 10/24/00 07:41PM >>>
>All,
>
>Did anyone consider using an OID for the value of this attribute.  That
>would remove any potential doubt about which form the vendor's name should
>have (e.g. Siemens vs Siemens AG).
>
>Cheers,                 ....Erik.
>
>
>-----Original Message-----
>From: Kurt D. Zeilenga [ mailto:Kurt@OpenLDAP.org]
><mailto:Kurt@OpenLDAP.org]> 
>Sent: Saturday, October 21, 2000 16:24
>To: mark_meredith@novell.com
>Cc: ietf-ldapext@netscape.com
>Subject: Comments: draft-mmeredith-rootdse-vendor-info-03.txt
>
>
>Mark,
>
>Here are some comments...
>
>    Kurt
>
>
>The abstract says: "MUST NOT be used for feature advertisement or
>discovery" yet section 3.1 describes exactly this.  
>
>4.1 vendorName
>   This attribute contains a single string, which represents the name
>   of the LDAP server implementer.
>
>I suggest the specification allow the vendorName to contain any
>string representing the name of the vendor.  In the world of
>OEM'ed software, the name of the implementor may not be the
>most appropriate name to place here.
>
>4.2 vendorVersion
>
>4.2 states "This string MUST be unique between two versions".
>I assume it's up to the vendor to determine what constitutes
>a version.
>
>5. Notes to Server Implementors
>
>I suggest, like HTTP vendor version strings, the I-D state that
>server implementors may make the vendorName and vendorVersion
>strings configuration items.  The reality is that clients will
>abuse these values and servers need to support spoofing.
>
>6. Notes to Client Developers
>
>It should be noted that an anomalies often on affect subset
>of implementations reporting the same version information.
>Most implementations support multiple platforms, have numerous
>configuration options, and often support plugins.
>
>Lastly, I believe Informational would be a more suitable category
>for this proposal.