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 - 16:23:55 EDT

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

    Hi Bob,

    You're right we've got different ideas (and goals).

    The current spec REQUIRES that particular notifications
    convey the semantic meaning (at least) of various
    IPP Printer and Job object attributes.

    That requirements CANNOT be tested in implementations,
    because there is no discussion of how a human user
    can possibly determine that the 'printer-name' value
    is the next word in the notification content.

    The IETF has NEVER let a protocol standard advance
    on the Internet 'standards track' (AFTER Proposed
    Std) that contains an untestable MUST.

    To meet your (and other PWG members) desires, simply
    delete all language about the content OR change it
    be SHOULD (RECOMMENDED) and punt on testing.

    Cheers,
    - Ira

    -----Original Message-----
    From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
    Sent: Tuesday, August 22, 2000 1:02 PM
    To: McDonald, Ira; Herriot, Robert; '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)]

    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:48:42 EDT