Subject: RE: IPP> Notification Requirements

From: "Gordon, Charles" <[email-masked]>
Date: Thu, 12 Feb 1998 10:36:06 -0500

The simplest way would be to restrict IPP to a specific set of
notification messages.  The localized version of the IPP client would
have these messages translated into the local language.  When the IPP
client reads the message from the IPP server, it would determine which
notification event occurred and produce the localized version version of
the message for it.

For a simple example, suppose IPP supports the following notification
messages.

1.  Print job %job-name% which was sent to you by %sender% was printed
on printer %printer% on %date% %time%.
2.  Print job %job-name% which was sent to you by %sender% was aborted
on %date% %time% because of errors on printer %printer%.
3.  Print job %job-name% which you sent to %receipient% has been printed
on printer %printer% on %date% %time%.

and so on....

The idea here is that we define a message for each type of event which
IPP will send notification of.  The strings can include tokens like
%job-name% which will be replaced by the client with strings which
represent the actual values assigned to them.

When the IPP server sends a message, it sends it in a format which the
IPP client can recognize.  For example, suppose the IPP server sends a
notification to a receipient that a job has been printed (message 1
above).  The IPP server formats the message so that client software can
recognize that it is a notification that event 1 happenned, and sends
values for the %job-name%, %sender%, and other tokens.  The IPP client
retrieves the localized text for notification event 1 and inserts the
values for the tokens into the message.  The localized message can now
be displayed to the user.

Well written Windows programs are designed so that they can be easily
localized.  All text is stored in a seperate file which can be localized
without changing the code.  If I write a Windows program which uses
English, I can send the 'resource' file (which contains all my English
text strings) to some translation house and have them provide localized
versions for all the languages I want to support.  Localized IPP clients
can be create in this fashion.  I would assume that other operating
systems also support localization one way or another.

I know the above example is rather simple, but I think it shows how
localization could be done.

________________________________________________________________________
________________________________
Charles Gordon
Osicom Technologies, Inc.
[email-masked]
http://www.digprod.com

> -----Original Message-----
> From:	Turner, Randy [SMTP:[email-masked]]
> Sent:	Thursday, February 12, 1998 9:45 AM
> To:	'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry; [email-masked]
> Subject:	RE: IPP> Notification Requirements
> 
> 
> Can you elaborate a little on the exact method for how a client would
> apply localization to a server-generated message?
> 
> Randy
> 
> 
> 	-----Original Message-----
> 	From:	Gordon, Charles [SMTP:[email-masked]]
> 	Sent:	Thursday, February 12, 1998 6:37 AM
> 	To:	'Carl-Uno Manros'; Roger K Debry; [email-masked]
> 	Subject:	RE: IPP> Notification Requirements
> 
> 	If localization of messages is a requirement (and it should be),
> I would
> 	suggest that messages be localized by software on the receiver's
> PC.
> 	This would work as follows:
> 
> 	1.  IPP server sends message (by whatever means) to an IPP
> client on the
> 	remote user's PC.  This message would be formatted to be easily
> machine
> 	readable.  
> 	2.  Software on remote user's PC retrieves the message and
> localizes it.
> 	3.  Localized message it displayed to user.
> 
> 	The advantage in this approach is that the IPP server does not
> need to
> 	support different languages and character sets.  Instead, IPP
> client
> 	software does this.  Since the client software is on the remote
> user's
> 	PC, the user would, presumably, have installed a localized
> version of
> 	the software, and the PC will be setup with the correct
> character set.
> 
> 	It will probably be desirable to make the original message sent
> from the
> 	IPP server to the client human readable as well as machine
> readable.
> 	This would allow users to read the message even if they don't
> have IPP
> 	client software.  This could be done by either generating the
> message as
> 	English text (the defacto International standard language)
> formatted to
> 	make parsing by software easy, or by generating a two part
> message where
> 	one part is text and the other part is machine readable.  
> 
> 	If email is used for notification messages (and it does seem
> like a good
> 	choice), then the message from the IPP server could be sent to a
> special
> 	mailbox setup at the remote site.  The IPP client software could
> be a
> 	specialized mail client which decodes the messages, localizes
> them, and
> 	displays them to the user.  If the user does not have IPP client
> 	software, he would still be able to access the messages with a
> standard
> 	mail client and read them in English.
> 
> 	That's just a suggestion for how I would approach the problem.
> The main
> 	point I am trying to make (which I am sure someone has already
> made) is
> 	that the IPP server should not have to localize notification
> messages.
> 	Localization should be done on the client side.
> 
> 
> ______________________________________________________________________
> __
> 	________________________________
> 	Charles Gordon
> 	Osicom Technologies, Inc.
> 	[email-masked]
> 	http://www.digprod.com
> 
> 	> -----Original Message-----
> 	> From:	Carl-Uno Manros [SMTP:[email-masked]]
> 	> Sent:	Wednesday, February 11, 1998 7:32 PM
> 	> To:	Roger K Debry; [email-masked]
> 	> Subject:	Re: IPP> Notification Requirements
> 	> 
> 	> Roger,
> 	> 
> 	> One requirement, which we have discussed earlier, but seems to
> have
> 	> been
> 	> forgotten lately, is the ability to request the human readable
> 	> notifications in different langauges.
> 	> 
> 	> E.g. I want to send a document for review to our offices in
> Japan and
> 	> want
> 	> to have any notifications to my collegue in Tokyo in Japanese,
> while I
> 	> want
> 	> to have my own notifications in Swedish :-)
> 	> 
> 	> Can we create a scenario for this?
> 	> 
> 	> Carl-Uno
> 	> 
> 	> 
> 	> At 08:22 AM 2/10/98 PST, Roger K Debry wrote:
> 	> >I have taken a pass at writing down a set of notification
> 	> requirements.
> 	> >They are in the PDF file attached to this note.  I'd be glad
> to take
> 	> >comments and suggestions and turn this into a formal
> requirements
> 	> >document, if you all feel that this would be useful.
> 	> >
> 	> >
> 	> >
> 	> >
> 	> >Roger K deBry
> 	> >Senior Technical Staff Member
> 	> >Architecture and Technology
> 	> >IBM Printing Systems
> 	> >email: [email-masked]
> 	> >phone: 1-303-924-4080
> 	> >
> 	> >Attachment Converted:
> 	> "C:\WINNT\profiles\cmanros\personal\Attach\notify.pdf"
> 	> >
> 	> Carl-Uno Manros
> 	> Principal Engineer - Advanced Printing Standards - 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]

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 12 Feb 1998 11:51:28 PST

Guys,

I think you are making it too easy.

There are a number of places that are multi-lingual and there is not
necessarily ONE localiced language (Florida, California, Canada and
Switzerland are concrete examples, not to mention the UN offices in New
York or the EU offices i Brussels).

So even if we encode all messages in some language independent way, we
might still need to indicate in the messages in which language they should
be displayed to a particular user.

Carl-Uno

>localization could be done.
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - 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]

---

From: James Walker <[email-masked]>
Date: Fri, 13 Feb 1998 16:01:36 -0600

You know, I seem to be getting a little bit confused in this whole
notification discussion.  When people are talking about a specific
set of notification messages, are they referring to the so-called
"human-readable" or "machine-readable" representation.

My take on it all is that, if we are to create a standard for IPP
notifications, then we should...

... explicitly define the specific IPP events that would cause a
	notification to be generated.  Various events have been
	discussed, including job completion, job progress, printer
	problems, and even more general object state transitions.

... explicitly define the information returned in the "machine-
	readable" representation.  Personally, I feel that the
	most flexible, extensible, and useful means of doing
	this is to say that "the object is the notification".
	Specifically, if I subscribe for some sort of job
	notification, then the "machine-readable" representation
	for a resultant notification would be the actual job
	object itself (presumably in the same application/ipp
	representation that would be returned as the result of
	a GetJobAttributes request).  The amount of information
	returned could be further limited by allowing the
	requested attributes to be specified (as in GetJobAttr's).

... be very vague about the information returned in the "human-
	readable" representation.  I feel that it is appropriate
	to say that a "human-readable" represenation MAY be
	requested or returned (while the "machine-readable" MUST
	be returned), and to say that, if returned, that "human-
	readable" representation would be part of a multipart
	MIME encoding, and to even possibly go as far as to say
	something about character sets and encodings.  But I
	think that it is going too far to standardize the specific
	"human-readable" text for each event.

one man's opinion...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX