WIMS> CIM> Deprecating (almost) all CurrentXxxx properties in CIM_Printer

WIMS> CIM> Deprecating (almost) all CurrentXxxx properties in CIM_Printer

Richard_Landau at Dell.com Richard_Landau at Dell.com
Tue Aug 9 17:07:06 EDT 2005


Ira, 
 
Again, thanks for the clarifications, particularly in an area that I'm
not familiar with (IPP).  Not to quibble *too* much, but it seems to me
that only the semantics of 'attributes-charset' and
'attributes-natural-language' are more subtle than described below.  The
fact that the value of 'natural-language-configured' is used in some
other calculation is not a description of *its* behavior.  That
calculation is part of the description of the behavior of
'attributes-natural-language'.  

 

And, anyway, if we limit near-term discussions to Printer, these
considerations don't arise.  

 

Good luck with the music festival.  

 

rick

 

 


________________________________

From: McDonald, Ira [mailto:imcdonald at sharplabs.com] 
Sent: Tuesday, August 09, 2005 15:53
To: Landau, Richard; McDonald, Ira; wamwagner at comcast.net; wims at pwg.org
Cc: Bumpus, Winston
Subject: RE: WIMS> CIM> Deprecating (almost) all CurrentXxxx properties
in CIM_Printer


Hi Rick,
 
More layers to the onion...
 
IPP operation requests all MUST include the special _operation_
attributes of 
'attributes-charset' and 'attributes-natural-language' which determine
the Printer's 
choices in operation responses.
 
If the Printer does NOT support the specified 'attributes-charset'
value, then the 
Printer MUST reject the request.  
 
If the Printer does NOT support the specified
''attributes-natural-language' value, 
then the Printer MUST ACCEPT the request and store the user's attributes
with 
the well-formed (but unknown) language tag and MUST respond using the 
'natural-language-configured' value for any reply text (i.e., the
Printer need not be 
omniscient)
 
So the semantics of 'Xxx-Configured' are more subtle than you describe
below.
 
Cheers,
- Ira
 

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com 

	-----Original Message-----
	From: Richard_Landau at Dell.com [mailto:Richard_Landau at Dell.com]
	Sent: Tuesday, August 09, 2005 3:29 PM
	To: imcdonald at sharplabs.com; wamwagner at comcast.net; wims at pwg.org
	Cc: Winston_Bumpus at Dell.com
	Subject: RE: WIMS> CIM> Deprecating (almost) all CurrentXxxx
properties in CIM_Printer
	
	

	Okay, here's another possibly way-off-center point.  

	 

	First, apparently I seriously misunderstood the (implied)
semantics of the CurrentCharSet and CurrentNaturalLanguage properties.
I apologize.  I assumed (always a bad strategy) that they were global
items that could in fact set the default behavior of the management
agent.  That is, behavior similar to prtGeneralLocalization, though that
does not permit character set and language to vary independently.  

	 

	However, I am now really puzzled about a useful interpretation
of the meaning of "Current" in these cases.  Two questions.  Easy one
first.  

	 

	1.  The printer MOF does not specify any read-write access for
properties.  The CIM default for this attribute is False.  Should we
attempt to correct this?  Do we think that these properties might permit
read-write access?  Do we think that any properties in CIM_Printer
should permit read-write access?  Such a declaration would be for
modeling only; implementations would still get to permit or forbid write
access, authorize it, etc.  

	 

	2.  Do we think that such properties are global to the
management agent or local to a management session?  If two users
simultaneously request management information in two different languages
(using some protocol mechanism outside these properties), do they see
different values of CurrentNaturalLanguage?  And how current is
"Current?"  Does the value returned describe the language in which this
particular response message is written, or does it refer to a global
setting in the printer?

	 

	I agree with Ira that the printer current values don't change.
I would not expect any such request to alter the value of
CurrentNaturalLanguage.  A deliberate SET operation might alter the
value, but only if the property is writable; see question 1.  

	 

	Is there a useful interpretation that we can agree on (and then
record in text in the new MOF), for the semantics of these properties?
Suggestions: 

	 

	- A CurrentXxxx property describes the behavior of the
management agent for all management request-response exchanges or
sessions, unless the request that initiates the session specifies
different behavior.  

	 

	- A request that specifies different behavior does not change
the value of the CurrentXxxx property.  

	 

	- The mechanism used by a request to specify different behavior
is beyond the scope of this MOF.  

	 

	- A CurrentXxxx property may or may not be settable by the end
user, as part of management policy.  The MOF declares that the property
as modeled may be writable.  Implementations may vary in their ability
to write the property, or to authorize writing by consumers, and so
forth.  

	 

	Would such semantics be useful to write down?  The current MOF
doesn't specify the behavior of these properties very clearly.  

	 

	If this whole topic is not completely off-base, we could just
add it to the list of non-cosmetic questions.  

	 

	Sorry for the length.  

	 

	rick

	 

	 
	 
________________________________

	From: McDonald, Ira [mailto:imcdonald at sharplabs.com] 
	Sent: Monday, August 08, 2005 22:26
	To: McDonald, Ira; 'wamwagner at comcast.net'; Landau, Richard;
wims at pwg.org
	Cc: Bumpus, Winston
	Subject: RE: WIMS> CIM> Deprecating (almost) all CurrentXxxx
properties in CIM_Printer
	
	
	Hi,
	 
	By the way, the corresponding IPP Printer attributes are called
	'charset-configured' and 'natural-language-configured'.  Given
that
	IPP and the Printer MIB frequently refer to the 'current
configuration',
	DMTF CIM property names of 'Current...' are fine if we deprecate
	all the other non-deterministic 'CurrentXxx' properties.
	 
	Cheers,
	- Ira
	 

	Ira McDonald (Musician / Software Architect)
	Blue Roof Music / High North Inc
	PO Box 221  Grand Marais, MI  49839
	phone: +1-906-494-2434
	email: imcdonald at sharplabs.com 

		-----Original Message-----
		From: owner-wims at pwg.org [mailto:owner-wims at pwg.org]On
Behalf Of McDonald, Ira
		Sent: Monday, August 08, 2005 6:46 PM
		To: 'wamwagner at comcast.net'; Richard_Landau at Dell.com;
wims at pwg.org
		Cc: Winston_Bumpus at Dell.com
		Subject: RE: WIMS> CIM> Deprecating (almost) all
CurrentXxxx properties in CIM_Printer
		
		
		Hi,
		 
		I agree with the proposal.  
		 
		However, I strongly DISAGREE with the creation of new
DefaultXxx
		properties to be used in place of
CurrentCharSet/NaturalLanguage.
		 
		We had this discussion during the development of IPP and
concluded
		that DefaultXxx has the wrong semantics, because they
CANNOT be
		overridden by the user.  They are the character set and
language
		for the values in the Printer Description class of
attributes (broadly, 
		everything except Status attributes).  A specific user
can request
		a Notification (for example) in a different
charset/language, but the
		Printer current values don't change.  This is NOT the
semantics
		of DefaultXxx on a Printer object.
		 
		Note that the user MUST specify the charset/language of
submitted
		string attributes with an IPP Job  - it's a protocol
error to omit them.
		 
		Cheers,
		- Ira
		 

		Ira McDonald (Musician / Software Architect)
		Blue Roof Music / High North Inc
		PO Box 221  Grand Marais, MI  49839
		phone: +1-906-494-2434
		email: imcdonald at sharplabs.com 

			-----Original Message-----
			From: owner-wims at pwg.org
[mailto:owner-wims at pwg.org]On Behalf Of wamwagner at comcast.net
			Sent: Monday, August 08, 2005 3:43 PM
			To: Richard_Landau at Dell.com; wims at pwg.org
			Cc: Winston_Bumpus at Dell.com
			Subject: Re: WIMS> CIM> Deprecating (almost) all
CurrentXxxx properties in CIM_Printer
			
			
			Rick,
			 
			Makes sense. Perhaps we got carried away in our
generalizations and missed the distinction.
			 
			I would see no benefit in changing the names of
urrentCharSet or CurrentNaturalLanguage   
			 
			Bill Wagner
			 

				-------------- Original message
-------------- 
				

				Re: Deprecating (almost) all CurrentXxxx
properties in CIM_Printer 

				Slight revision to the proposal:
Deprecate all the CurrentXxxx properties in favor of the corresponding
DefaultXxxx properties, except CurrentCharSet and
CurrentNaturalLanguage.  

				These last two properties, CharSet and
NaturalLanguage, record the character set and natural language being
used for management, not for printing.  They are properties of the
printer controller, not properties of print jobs.  Since they are
asynchronous with printing functions, they do not suffer from the
ambiguities of the other CurrentXxxx properties in complex printers.
Also, neither of these properties has a corresponding DefaultXxxx
property.  Therefore these two properties must be retained.  

				Summary: 

				CurrentPaperType
deprecate; use DefaultPaperType instead 
				CurrentLanguage         deprecate; use
DefaultLanguage 
				CurrentMimeType         deprecate; use
DefaultMimeType 
				CurrentCapabilities
deprecate; use DefaultCapabilities 

				CurrentCharSet                  retain 
				CurrentNaturalLanguage          retain 

				I recall that some exceptions were
mentioned, but I think we all mistakenly referred to CurrentLanguage
instead of CurrentCharSet during the discussion.  

				Addendum to proposal: we could change
the *names* of the two remaining CurrentXxxx properties to
DefaultCharSet and DefaultNaturalLanguage and then be rid of all the
CurrentXxxx properties.  (Actual process: add new properties with
identical syntax and semantics but new names, and then deprecate the old
properties.)  Only half kidding.  

				Comments, please.  

				rick 

				------------------------- 
				Richard_Landau at dell.com, System Mgt Arch
& Stds 
				+1-512-728-9023, One Dell Way, RR5-3 Box
8352, Round Rock, TX 78682 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20050809/26bf4ba6/attachment-0001.html


More information about the Wims mailing list