Is there a global mechanism to avoid string collisions?
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, October 26, 2000 7:44 PM
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.
*****************************************************************************
This confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
******************************************************************************