Subject: IPP> Notification Requirements

From: Roger K Debry <[email-masked]>
Date: Tue, 10 Feb 1998 11:22:28 -0500

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

---

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

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:
> >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: "Turner, Randy" <[email-masked]>
Date: Thu, 12 Feb 1998 06:45:18 -0800

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.

---

From: Harry Lewis <[email-masked]>
Date: Thu, 12 Feb 1998 10:39:26 -0500

I agree with this point...

>The main point I am trying to make... is that the IPP server should not
>have to localize notification messages. Localization should be done on
>the client side.

Which invoked the question...

>apply localization to a server-generated message?

This is accomplished by defining a (limited) set of notification messages
 which, even in some encoded form, may be distinguished (and translated)
 by an application. If someone thinks there is a need to "ramble on"
inside a print job notification, please identify and give an example.

Harry Lewis

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 12 Feb 1998 08:43:47 -0800

I thought this was what you meant. I just wanted to make it clear that
client-localization requires defining a strict set of possible messages,
with an associated token or code so that the client knows how to look up
the localized version of this message in a localization dictionary (or
catalog, or whatever). I wonder if absolutely restricting the set of
messages that can be sent from server to client is too constraining?

Randy

	-----Original Message-----
	From:	Gordon, Charles [SMTP:[email-masked]]
	Sent:	Thursday, February 12, 1998 7:36 AM
	To:	'Turner, Randy'; [email-masked]
	Subject:	RE: IPP> Notification Requirements

	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.

	> 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]

	> 	Localization should be done on the client side.
______________________________________________________________________
	> __
	> 	> One requirement, which we have discussed earlier, but
seems to
	> have
	> 	> 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
	> 	> >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
	> 	> Principal Engineer - Advanced Printing Standards -
Xerox
	> Corporation

---

From: Harry Lewis <[email-masked]>
Date: Thu, 12 Feb 1998 12:46:00 -0500

I agree.

>The idea here is that we define a message for each type of
>event which IPP will send notification of.

I've attached a file which attempts to express requirements and
corresponding message types.

>I wonder if absolutely restricting the set of messages that can
be sent from server to client is too constraining?

Maybe, but a practical approach to content can alleviate most
concerns.

There are several ways to go about standardizing content. A seriously complex
route is to allow recipient to request specific content per notification type
per registration (someone mentioned this on the call, today). A complex  method
is to define content per notification type (ex. Job Complete events don't need
to indicate the jobs position in the queue). A simpler approach is to define a
pragmatic set of useful attributes, fixed for all notifications, sometimes
having no valid value.
The downside of a simpler approach is baggage which might to be carried with
notifications. In general, notification traffic should be reduced via proper
registration, un-registration, registration "time-to-live", and filters - not
event content. We should strive for a useful set of content to be carried with
each event such as:
event-type (see attached chart)
number-of-intervening-jobs
job-k-octets (if known)
job-k-octets-processed
job-impressions (if known)
job-impressions-interpreted
job-impressions-completed
impressionsCompletedCurrentCopy
sheetCompletedCopyNumber
sheetCompletedDocumentNumber
copiesRequested
copyType
outputDestination
jobStateReasons1

Harry Lewis

---

From: [email-masked]
Date: Thu, 12 Feb 1998 10:27:20 PST

> messages that can be sent from server to client is too constraining?

For one existing example along these lines, look at the Adobe
Printer Description File specification.  Part of the specification
for a printer model is a complete list of messages generated by the
printer, and the PDF can also provide translations for the messages. 

So the set of messages can be "relatively" restricted, rather than
"absolutely." ;-)

::  David Kellerman         Northlake Software      503-228-3383
::  [email-masked] Portland, Oregon        fax 503-228-5662

---

From: "Gordon, Charles" <[email-masked]>
Date: Thu, 12 Feb 1998 15:27:11 -0500

I think you're missing something here.  (One of us is anyway).  If we
send a notification message to a user, it is reasonable (I think) to
expect that user to use a PC which supports a language he understands to
read the message.  The localization will be done by the IPP client
software on that PC.  Therefore the client software will also be
localized to the user's language.  So the IPP client software will
generate a notification message in the user's language.  The IPP server
does not even have to know what language that is.  As long as the user
uses a PC with IPP software which has been setup to support his
language, everything should work fine.

In other words, the user who receives the message chooses the language
the message is displayed in by selecting a PC with IPP software which
has already been setup to support his language.
________________________________________________________________________
________________________________
Charles Gordon
Osicom Technologies, Inc.
[email-masked]
http://www.digprod.com

> Sent:	Thursday, February 12, 1998 2:51 PM
> To:	[email-masked]
> 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
> 
> At 07:36 AM 2/12/98 PST, Gordon, Charles wrote:
> >notification messages.  The localized version of the IPP client would
> >have these messages translated into the local language.  When the IPP
> >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.
> >
> >IPP will send notification of.  The strings can include tokens like
> >%job-name% which will be replaced by the client with strings which
> >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
> >retrieves the localized text for notification event 1 and inserts the
> >values for the tokens into the message.  The localized message can
> now
> >Well written Windows programs are designed so that they can be easily
> >without changing the code.  If I write a Windows program which uses
> >can be create in this fashion.  I would assume that other operating
> >I know the above example is rather simple, but I think it shows how

---

From: "Mitchell,Barbara" <[email-masked]>
Date: Thu, 12 Feb 1998 23:44:57 PST

Please take Jorg Thiry and Barbara Mitchell off this dl. 

Many thanks
Barbara
----------
From: [email-masked]
To: [email-masked]
Subject: RE: IPP> Notification Requirements
Date: 12 February 1998 10:27