Subject: RE: IPP> Re: Root OID for IPP Printer Schema

From: "Manros, Carl-Uno B" <[email-masked]>
Date: Fri, 21 Apr 2000 13:18:45 -0700

Bruce,

I think we have an added problem in that Sun also intends to use this branch
for some of their private extensions which go beyond the standardized
values. I think that mixing the two on the same OID branch would cause more
confusion then what it is worth.

Carl-Uno

Carl-Uno Manros
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked] 

-----Original Message-----
From: Bruce Greenblatt [mailto:[email-masked]]
Sent: Friday, April 21, 2000 1:12 PM
To: [email-masked]; Alexis Bor
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: IPP> Re: Root OID for IPP Printer Schema

I think this is OK.  For example, the S/MIME RFCs have OIDs from the RSA
arc, e.g.:

SecureMimeMessageV3
  { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }

This is in RFC 2633, which is an IETF Standards Track document.  This it is
politcally correct to have an OID that is in a corporate arc in a standards
document.  My recommendation, is to just continue using the ones that are
in the draft, and not worry about it.

Bruce

At 01:42 PM 4/21/2000 -0600, [email-masked] wrote:
>
>
>
>Personally, I don't care about "politically" correct, I'm simply trying to
>be correct.
>
>I think a standards track RFC will carry the IETF copyright meaning the
>IETF is ultimately responsible for "change control" and would (presumably)
>desire not to have OIDs managed and maintained by a private enterprise.
>
>Granted, there's not a lot of dynamics available that could inadvertently
>"hose" an assigned OID subtree... no matter where it lies.
>
>Harry Lewis
>IBM Printing Systems
>
>
>
>
>"Alexis Bor" <[email-masked]>
>Sent by: [email-masked]
>04/21/00 01:02 PM
>
>
>        To:     "Manros, Carl-Uno B" <[email-masked]>, "Bruce
>Greenblatt"
><[email-masked]>, Harry Lewis/Boulder/IBM@IBMUS,
><[email-masked]>, <[email-masked]>
>        cc:     <[email-masked]>
>        Subject:        RE: IPP> Re: Root OID for IPP Printer Schema
>
>
>All we are doing is making IETF more politically correct, and thus making
>politics slow down the technical process...  Are we going to go through
>several version of the draft arguing over this???
>
>Let's just choose one and move on...    It will not impact the sales of
>any
>products nor the operation of any protocol...
>
>-- Alexis
>
>Alexis Bor
>Directory Works, Inc.
>[email-masked]
>http://www.directoryworks.com
>
>-----Original Message-----
>From: Manros, Carl-Uno B [mailto:[email-masked]]
>Sent: Friday, April 21, 2000 11:33 AM
>To: Bruce Greenblatt; [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]
>Subject: RE: IPP> Re: Root OID for IPP Printer Schema
>
>Bruce,
>
>It is politically incorrect. We had objections raised in IET47 on this.
>
>Carl-Uno Manros
>IETF IPP Chair
>
>
>-----Original Message-----
>From: Bruce Greenblatt [mailto:[email-masked]]
>Sent: Friday, April 21, 2000 11:26 AM
>To: [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: IPP> Re: Root OID for IPP Printer Schema
>
>
>What's wrong with continuing to use the one from Sun?  As long as it is
>unambiguous, who cares?
>
>Bruce
>
>At 11:59 AM 4/21/2000 -0600, [email-masked] wrote:
>>
>>
>>
>>The Internet Printing Protocol Working Group is developing an Internet
>>Draft describing an LDAP Schema for Printer Services.
>>
>>http://www.ietf.org/internet-drafts/draft-ietf-ipp-ldap-printer-schema-00.
t
>
>xt
>>
>>
>>For expediency, the initial draft specifies OIDs from a Sun Microsystems
>>private enterprise subtree. In preparation for a standards track document
>>we would like these OIDs to be routed in a standards subtree. We want to
>>harmonize with any convention that may exist within the LDAP community
>for
>>registering this subtree. Will the LDAP group make the request for an
>>assigned OID subtree or would you prefer for the IPP group to make the
>>request?
>>
>>Harry Lewis
>>
>>
>>
>==============================================
>Bruce Greenblatt, Ph. D.
>Directory Tools and Application Services, Inc.
>http://www.directory-applications.com
>Sign up for our LDAP Technical Overview Seminar at:
>http://www.acteva.com/go/dtasi
>
>
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi

---

From: James Kempf <[email-masked]>
Date: Fri, 21 Apr 2000 13:27:01 -0700 (PDT)

I'll talk to IANA about deriving one from 1.3.6.1 for the SLP template
translation draft, and then you can use that one for the IPP printer
schema which I think was fashioned according to the draft. That will
fix the problem for all schema derived according to the template
translation draft (unless, of course, you prefer to have a unique OID for the 
printer schmea).

Can anybody send me the email address of the person I need to
contact at IANA for the OID assignment, and Ian McDonald's email
address (presuming he's still working on the printer schema) so
I can talk to him about it? 

Thanx.

		jak

>Resent-Date: Fri, 21 Apr 2000 12:43:30 -0700 (PDT)
>From: [email-masked]
>X-Lotus-FromDomain: IBMUS
>To: "Alexis Bor" <[email-masked]>
>cc: [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
>Date: Fri, 21 Apr 2000 13:42:19 -0600
>Mime-Version: 1.0
>Content-Disposition: inline
>Resent-Message-ID: <"e-9vgC.A.IdE.Q9KA5"@glacier>
>Resent-From: [email-masked]
>X-Mailing-List: <[email-masked]> 
>X-Loop: [email-masked]
>Resent-Sender: [email-masked]
>
>
>
>
>>http://www.ietf.org/internet-drafts/draft-ietf-ipp-ldap-printer-schema-00.t
>
>xt
>>
>>

---

From: Bruce Greenblatt <[email-masked]>
Date: Fri, 21 Apr 2000 13:30:05 -0700

Well, if Sun doesn't want you to use their arc for this, that is a
different problem altogether.  If it will help, I'm certainly willing to
donate an arc off of my branch of the OID tree:

1.3.6.1.4.1.5515.

I've already used a couple of branches underneath this, but I'm willing to
allocate: 1.3.6.1.4.1.5515.3 for your use.

Bruce

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 21 Apr 2000 14:57:30 -0700

Hi James,

I don't see any base arc in your SLP to LDAP translation
spec for all SLP templates to allocate below.  But we
have some complications anyway.

We referred to your translation spec a good deal, BUT,
during development of the LDAP schema, folks from IBM,
Sharp, and Xerox indicated that they wanted an LDAP
printer schema that was independent of SLP (and shorn
of the SLP base attributes).

So our actual draft defines 6 object classes:

slpServicePrinter - aux class for SLP registered printers
servicePrinter - abstract class - to be renamed 'printerAbstract'
printerService - base structural class for printers
printerServiceAuxClass - aux class for adding printer to
	some other object class
printerIPP - aux class for IPP printers
printerLPR - aux class for LPR printers

(the first one defines the SLP standard attributes for
attachment to either 'printerService' structural or
'printerServiceAuxClass' aux objects)
(the last two are attached to one of the preceding two)

So we need OIDs for six classes and a number of attributes.

There are a lot of deployed LDAP-capable directories that
have proprietary printer objects or ones from other standards
(like DMTF's CIM printer).  It proves useful to use the
'printerServiceAuxClass' to augment these existing printer
objects with interoperable standardized attributes.

Hope this helps set some context.

Cheers,
- Ira McDonald, co-author LDAP printer schema
  High North Inc

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, April 21, 2000 2:08 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: IPP> Re: Root OID for IPP Printer Schema

>donate an arc off of my branch of the OID tree:

No, it's not a matter of "Sun not wanting to", it's just that it seems there
is some amount of unhappiness about using a Sun-specific arc. Since
I put the OID in the draft, we're perfectly happy to donate the OID.

>allocate: 1.3.6.1.4.1.5515.3 for your use.

It sounds to me like most people would prefer a neutral arc, not
allocated to any company, but I can use this OID if there is no
objection.

What do people think? Should I use Bruce's or go to IANA for one?

		jak

---

From: "Hugo Parra" <[email-masked]>
Date: Tue, 25 Apr 2000 17:01:07 -0600

My vote is for having neutral OIDs (OIDs not associated with any one company) allocated for the LDAP schema(s) for printers.  It's nice to know that SUN doesn't plan to use the OIDs for any other purpose, but why should the industry as a whole have to depend on any one company's OID management when IANA is set up for that purpose?  Again, if the overhead for securing new OIDs is low, it makes sense to me to go down that path.

Two cents.
-Hugo

>>> James Kempf <[email-masked]> 04/25/00 04:43PM >>>
I think I understand now what some of the confusion around the OIDs taken
from the SLP template conversion draft might be.

I'm looking at an Internet draft, draft-sun-ldap-print-schema-00.txt,
done by Ken Jones of Sun which appears to be a Sun-specific LDAP schema for
printers, dated this Feburary. This draft has *ABSOLUTELY NOTHING* to do with 
draft-ietf-svrloc-template-conversion-05.txt, which is an official 
document of the SLP working group, on track for an informational RFC. As Ludovic 
pointed out, the fact that the OIDs were reserved means that they *WILL NOT* be 
used for anything else, and that they explicitly belong to the SLP working
group to use in the RFC. Sun won't be using them or deriving anything from them 
for any internal purpose.

If people are still uncomfortable with having Sun allocated OIDs in
the schema, I have a request pending at IANA to get a special OID
for the draft. I will not follow up on the request unless I hear
some strong voices to the contrary.

I'd also suggest that someone from the IPP group follow up with Ken
and see whether he might not be interested in using the standardized
schema (I'll try on my end as well).

		jak