IPP Mail Archive: RE: IPP>NOT mailto feature from IETF meeti

IPP Mail Archive: RE: IPP>NOT mailto feature from IETF meeti

RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The IPPNotification I-Ds will now go the IESG)]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Aug 22 2000 - 15:07:14 EDT

  • Next message: McDonald, Ira: "RE: IPP> machine readable etc. - why Harry is right"

    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 - 15:27:05 EDT