DMTF Change Request

DMTF Confidential

All changes to be submitted by the Working Group Chair (or designee) after approval by the working group.  

The Change Request sample (http://www.dmtf.org/members/zdata/CRTemplateSample.html) contains more detailed information on how to complete the template.

 DMTF Change Request Number   [sysdevCR006655]

The change request number in the format used by the working group where it is created. Each workgroup shall use a format that ensures uniqueness across the DMTF

[RBL] Put the number right in here.

CR Owner Name, Email  [My Name, my.name@company.com]

Name of the person who owns the change request, and their email address.

Errata   [Yes/No]

Errata are serious errors in a released, final specification.  This can be a document or CIM schema.  Errata change requests MUST not be combined with non-errata content in the same change request.  If an Errata applies to multiple versions of a released specification or schema, they MUST be listed in incorporating change section below.

Short Description

A short description of the change.  In the case of change requests for the CIM schema, this description MAY be used when the change is applied in CVS or in the header of the MOF.  The description SHOULD clearly describe the change(s) made.

[RBL] And keep the short description short.  

Spec, Document or Model(s) Being Changed   [Device Model]

For specifications, the DSP number of the specification, e.g. DSP004.  If this is a new submission, the name of the specification.  For documents, the name of the document, e.g. CIM Technical Note.  For models, the name of the model, e.g Device, System, Core, Database, Application, Policy, Support.

Spec, Document or Model Version Incorporating the Change  [V2.9 Final]

The version where the change will appear.  

For CIM schemas, the version prior to company review will contain .1000, e.g. V2.9.1000.   Changes incorporated into the company review release are designated as Vx.x company review, e.g. 2.10 company review.  Changes incorporated into the preliminary CIM release are designated as Vx.x preliminary, e.g. V2.10 preliminary.  Changes incorporated into a final CIM release are designated as Vx.x final, e.g. V2.10 final.  Changes to final CIM schema versions MUST also be tagged as errata.

Filename(s) Incorporating the Change [Device_USB.mof]

This section lists the actual file name(s) where the change will be made.

Date Originated  [mm/dd/yyyy]

This is the date when the change request was originally created by the owner.

Date of Last Revision of the Change Request [mm/dd/yyyy]

This is the date when the change request is revised by the owner.

Dependencies   [smwgCR00567,sysdevCR00555]

This section lists any dependencies that the change request has on the approval of other change requests.  

Terminology

The terminology used in this CR should conform to the "Rules for the structure and drafting of International Standards", 5th Edition, 2005 available at:

http://isotc.iso.org/livelink/livelink.exe/fetch/2000/2122/3146825/4229629/4230450/4230456/ISO_IEC_Directives__Part_2__Rules_for_the_structure_and_drafting_of_International_Standards__2004__5th_edition___pdf_format_.pdf?nodeid=4230517&vernum=0

Particular attention shall be paid to Annex H which lays out guidelines for the expression of provisions.

 

Background/Rationale (Explanation of the background and reason(s) for the requested change, and supporting documentation):

As part of the PWG/DMTF Work Register dated 2005/05/12, the Printer Working Group (PWG) is updating the printing-related classes in the CIM data model.  PWG is submitting a series of Change Requests to update the CIM model to align with the current model developed in the PWG.  

The changes will be proposed in three phases.  

1.      Editorial and minor technical updates.  These changes will be carefully selected not to impact any existing implementations.  Depending on the scope of changes, several Change Requests may be needed to cover the several classes involved.

This phase includes

·        Changes in MappingStrings, both corrections and additions.  This editing will make informative, not normative, changes to many properties in several of the printing-related classes.  Some changes are required due to a new format for references to certain external specifications.  

·        Changes in ModelCorrespondences, again both corrections and additions. 

·        Addition of some new enumerated values for, e.g., printer languages that have been added to the PWG enumerations since the last update to the printing-related CIM classes.  The new enum values will be added carefully to the existing ValueMaps.  It is also possible that some current enum values will be deprecated.  

·        Corrections for typos. 

2.      Structural changes.  Some properties need to be moved, changed, or eliminated.  Existing implementations will continue to function, but new implementations will be advised to use different properties. 

·        Several properties in the CIM_Printer class are appropriate to a print service but not to a printer device.  These properties will be moved, that is, the original property in CIM_Printer will be deprecated, and a new property with appropriate name and semantics will be added to CIM_PrintService.

·        A few properties in CIM_Printer are ambiguous and cannot be implemented interoperably as they are currently defined.  Their definitions will be updated to permit interoperable implementations. 

·        A few properties in CIM_Printer cannot be implemented interoperably at all in many current printer devices.  These properties will be deprecated, with explanation of how applications should accomplish similar goals.  

3.      Extensions.  The PWG models for printing related devices and services include many properties that need to be managed but are not currently represented in CIM at all.  If these properties are to be visible to CIM-based management applications, then they must appear in the CIM model.  

The current PWG printer device model, as embodied in the SNMP Printer MIB v2, RFC3805, contains many properties Some examples:

·        Printer console displays and lights, and cover and other interlocks

·        Printer input and output trays containing media

·        Printer media paths that control the layout of page images on physical sheets

·        Printer toners, colorants, and other supplies

·        Printer communication channels and language interpreters

·        Printer counters for pages and sheets printed in various operational modes

The CIM model will be extended to include these important management objects.  This will probably require extensions to the CIM_Printer class and the use of other CIM classes to represent the capabilities, settings, and counters required.  

Looking to the future after this short-term work is completed, PWG will propose similar updates to the CIM model of Print Service.  The current PWG print service model, as embodied in the IPP Print Service model, RFC2911 et al., contains a number of properties not in CIM_PrintService. 

·        [Ira, please fill in a sample list of IPP properties missing from PrintService.]

·         . . .

The CIM_PrintService class will also be extended, and additional classes may be required, again, to represent the capabilities, settings, and counters required.  

This current Change Request is part of Phase 1.  

 

 Requested Change (Change information such as details before/after the change, readable/indented MOF, and/or references to "Uploaded" MOF and other documents if the changes are too lengthy to include inline):

In addition, if there are any conditions or constraints, they should be clearly identified in this section.

 

Discussion Points (Summary of decisions and discussions of the WG in creating this CR) :

Any additional discussion points for the change request that were discussed in email or during a TC call SHOULD also be captured in this section.

This section MAY include email discussions to close out discussion points, or feedback from a ballot, comments, and content on how the comments were addressed.  Each set of ballot comments SHOULD be separately designated.

For Example,

000 Ballot Feedback:

Company:

Comment:

Resolution:

 

Change History (Mandatory after submission to the TC, May be used by the WGs):  

Version

Date 

Short description of changes

001

08/04/2004

Update after initial ballot

 

 

 

Note that this document is labeled as "DMTF Confidential".  It is intended only for DMTF member companies and alliance partners.  This Change Request may be withdrawn or modified by subsequent Change Requests.

All submissions MUST comply with the DMTF Patent and Technology policy (http://www.dmtf.org/about/policies/patent-10-18-01.pdf)

Template Sample Version 2.0.0c.