IPP Mail Archive: RE: IPP> Notification Requirements

IPP Mail Archive: RE: IPP> Notification Requirements

RE: IPP> Notification Requirements

Ron Bergman (rbergma@dpc.com)
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.

On Thu, 12 Feb 1998, Gordon, Charles wrote:

> 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.
> cgordon@osicom.com
> http://www.digprod.com
>
> > -----Original Message-----
> > From: Turner, Randy [SMTP:rturner@sharplabs.com]
> > Sent: Thursday, February 12, 1998 11:44 AM
> > To: 'Gordon, Charles'
> > Cc: 'ipp@pwg.org'
> > 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:CGordon@wal.osicom.com]
> > Sent: Thursday, February 12, 1998 7:36 AM
> > To: 'Turner, Randy'; ipp@pwg.org
> > 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.
> > cgordon@osicom.com
> > http://www.digprod.com
> >
> > > -----Original Message-----
> > > From: Turner, Randy [SMTP:rturner@sharplabs.com]
> > > Sent: Thursday, February 12, 1998 9:45 AM
> > > To: 'Gordon, Charles'; 'Carl-Uno Manros'; Roger K Debry;
> > ipp@pwg.org
> > > 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:CGordon@wal.osicom.com]
> > > Sent: Thursday, February 12, 1998 6:37 AM
> > > To: 'Carl-Uno Manros'; Roger K Debry; ipp@pwg.org
> > > 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.
> > > cgordon@osicom.com
> > > http://www.digprod.com
> > >
> > > > -----Original Message-----
> > > > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com]
> > > > Sent: Wednesday, February 11, 1998 7:32 PM
> > > > To: Roger K Debry; ipp@pwg.org
> > > > 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: rdebry@us.ibm.com
> > > > >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: manros@cp10.es.xerox.com
>