Subject: RE: IPP> Notification Requirements

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

I don't think restricting the set of notification messages is too much
of a limitation.  After all, all of the messages are generated by
software.  Therefore, they will be canned messages anyway.  

Defining a set of messages to support will not prevent us from adding
new ones later.  If an IPP client receives a new message type which it
doesn't recognize, it can either display the English version of it
(supplied by the IPP server), or simply tell the user that it received a
message it doesn't understand.  New messages won't be supported by old
software, but this just gives users an incentive to buy new software
from us :-).
________________________________________________________________________
________________________________
Charles Gordon
Osicom Technologies, Inc.
[email-masked]
http://www.digprod.com

> -----Original Message-----
> From:	Turner, Randy [SMTP:[email-masked]]
> Sent:	Thursday, February 12, 1998 11:44 AM
> To:	'Gordon, Charles'
> Cc:	[email-masked]'
> Subject:	RE: IPP> Notification Requirements
> 
> 
> 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.
> 
> 
> ______________________________________________________________________
> __
> 	________________________________
> 	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: Ron Bergman <[email-masked]>
Date: Thu, 12 Feb 1998 09:16:13 -0800 (Pacific Standard Time)

I would suggest that each message be preceded by the message number so
that the server need only look at this one piece.

	Ron Bergman
	Dataproducts Corp.