I think that you are making very different assumptions about localization of
Human Consumable, i.e. email text/plain than I am.
My assumption (which I think is shared by other PWG members as well) has
been that the Human Consumable message is intended to convey a meaning to
the user and each vendor is free choose a format that best accomplishes that
task (a value add). In English a vendor could use name value pairs or
something closer to English sentences. The names could be the IPP keyword
or something else, e.g. "printer-name" versus "printer name" versus
"printer's name". In most other languages, the IPP keyword is quite
meaningless.
I believe that it would be difficult for the PWG to decide on a standard
format in English. It would be even more difficult to specify a format for
numerous other languages. If we had a standard format, then some clients
might try to parse it and we stated in the beginning that we didn't want
clients to parse
We designed the Machine Consumable format for the case where the machine
needs to parse the Event Notification.
The examples in the spec were intended to show several different ways a
vendor might format messages. The examples for the message body include:
Example 1 with name value pairs:
printer: tiger
job: financials
job-state: completed
Example 2 with free text:
Printer tiger has stopped with a paper jam.
Example 3 sentences for each of 3 attributes (in Danish):
Printerens navn er 'tiger'.
Printeren er standset.
Aarsagen er papir stop.
Example 4 name value pairs in French (deleted from mailto spec)
imprimeur: tigre@def.com
état: arrêté
raison: papier coincé
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
> Sent: Tuesday, August 22, 2000 12:07 PM
> To: 'Herriot, Robert'; McDonald, Ira; 'jkm@underscore.com'
> Cc: 'ned.freed@innosoft.com'; ipp@pwg.org
> Subject: RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
> The IPPNotification I-Ds will now go the IESG)]
>
>
> Hi Bob,
>
> You just said the spec 'leaves phrasing ... of messages
> to each vendor'. But the spec REQUIRES various content
> for each message (such as 'printer-name').
>
> I believe that some guidance (at least) should be in
> the spec about how, in any language, that content is
> provided.
>
> Since 'printer-name' is NOT French, how is the fact
> that the content includes a value for 'printer-name'
> known to the end user? If each vendor translates not
> only free-form text (like status messages) but
> attribute names and attribute keyword values
> independently (and often product by product,
> sadly), then where's the benefit to the end user?
> Three different printers emitting human-readable
> email notifications in French that are fully product
> unique?
>
> There are approaches to minimize this problem, like a
> structured format for layout of the 'human-readable'
> phrases (which might always include the English
> original name for the attribute in parentheses, e.g.).
>
> Cheers,
> - Ira McDonald, consulting architect at Xerox and Sharp
> High North Inc
>
> -----Original Message-----
> From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
> Sent: Monday, August 21, 2000 2:17 PM
> To: McDonald, Ira; 'jkm@underscore.com'
> Cc: 'ned.freed@innosoft.com'; ipp@pwg.org
> Subject: RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
> The IPPNotification I-Ds will now go the IESG)]
>
>
> Rather than saying that 'mailto' dodges the I18N issue, could
> you say what
> you think should be added to the spec?
>
> The current 'mailto' spec presumes knowledge of email. It specifically
> leaves the phrasing (and translation) of messages to each
> vendor. So the
> translation of 'job-id' is not an issue that the spec need
> address. However,
> the spec does contain examples in both English and Danish.
>
> I did have a French example, but removed it because of the
> difficulty of
> displaying non-ascii characters in an RFC. I could have used
> quoted-printable encoding, but then the French would be hard
> to read. Other
> encoding would have been even harder to read.
>
> Bob Herriot
>
> > -----Original Message-----
> > From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
> > Sent: Friday, August 18, 2000 7:16 PM
> > To: 'jkm@underscore.com'; McDonald, Ira
> > Cc: 'ned.freed@innosoft.com'; ipp@pwg.org
> > Subject: RE: IPP>NOT mailto feature from IETF meeting (RE:
> IPP> ADM -
> > The IPPNotification I-Ds will now go the IESG)]
> >
> >
> > Hi Jay,
> >
> > The IPP 'mailto:' notification method recommends
> > suitable content for the human-readable notification,
> > while gracefully dodging the issues of I18n for
> > tagging of that content.
> >
> > How does a user know that the next few characters
> > are 'job-id' rather than something else?
> > Are there 'labels' that are translations of the intent
> > (if not the name) of IPP attributes in the notification?
> >
> > Is the notification an actually linguistically correct
> > _whole_sentence_ in the target notification language?
> > How can we have a standardized email notification
> > that doesn't address the human usability of the
> > content?
> >
> > Cheers,
> > - Ira McDonald
> >
> > -----Original Message-----
> > From: Jay Martin [mailto:jkm@underscore.com]
> > Sent: Friday, August 18, 2000 6:51 PM
> > To: McDonald, Ira
> > Cc: 'ned.freed@innosoft.com'; ipp@pwg.org
> > Subject: Re: IPP>NOT mailto feature from IETF meeting (RE:
> IPP> ADM -
> > TheIPPNotification I-Ds will now go the IESG)]
> >
> >
> > Ira,
> >
> > No one ever, *ever* said I18N in mail messages wasn't difficult.
> > Don't know how you came to that conclusion.
> >
> > In fact, with the exception of Tom Hastings (big surprise),
> > there hasn't been a word said on this thread by anyone
> > else about I18N in email notifications, except for your
> > comments and the interesting side comment by Ned.
> >
> > ...jay
> >
> >
> > "McDonald, Ira" wrote:
> > >
> > > Hi Ned,
> > >
> > > Thanks - you're the only person who has reinforced my
> > > periodic comments that the I18N for the stuff in the
> > > 'simple text' email notifications is a nice juicy
> > > problem - since IPP and most (or all?) shipping IPP
> > > Printer implementations define support for multiple
> > > human languages and charsets.
> > >
> > > And the fact that a client can ask for a notification
> > > in some other charset than UTF-8 further complicates
> > > I18N, because the obvious starting point (message
> > > catalogs in UTF-8) leads to smashed characters in
> > > many local charsets.
> > >
> > > I think the IPP 'mailto:' notification method should
> > > be a good deal more complete on this I18N topic.
> > >
> > > Cheers,
> > > - Ira McDonald, consulting architect at Xerox and Sharp
> > > High North Inc
> > >
> > > -----Original Message-----
> > > From: ned.freed@innosoft.com [mailto:ned.freed@innosoft.com]
> > > Sent: Friday, August 18, 2000 8:21 AM
> > > To: pmoore@peerless.com
> > > Cc: David_Kellerman@nls.com; kugler@us.ibm.com; ipp@pwg.org
> > > Subject: Re: IPP>NOT mailto feature from IETF meeting (RE:
> > IPP> ADM -
> > > TheIPPNotification I-Ds will now go the IESG)]
> > >
> > > <...snip...>
> > >
> > > Frankly, the bigger problem with this stuff is i18n support
> > for the text.
> > > But that's a different topic.
> > >
> > > IMO the supposed difference between simple text and a
> > structured report is
> > a
> > > chimera. Email support in general is another matter, of course.
> > >
> > > Ned
> >
>
This archive was generated by hypermail 2b29 : Tue Aug 22 2000 - 16:11:04 EDT