IFX Mail Archive: RE: IPP> RE: IFX> New data types [for l

RE: IPP> RE: IFX> New data types [for long text & octetString for IPP WG a genda]

From: Manros, Carl-Uno B (cmanros@cp10.es.xerox.com)
Date: Fri Mar 09 2001 - 12:46:57 EST

  • Next message: pmoore@netreon.com: "RE: IPP> RE: IFX> New data types [for long text & octetString for IPP WG a genda]"

    Don,

    I agree with you (sorry Tom).

    Carl-Uno

    Carl-Uno Manros
    Manager, Print Services
    Xerox Architecture Center - 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

    -----Original Message-----
    From: don@lexmark.com [mailto:don@lexmark.com]
    Sent: Friday, March 09, 2001 4:58 AM
    To: Hastings, Tom N
    Cc: gsonger@netreon.com; pmoore@netreon.com; ifx@pwg.org; ipp@pwg.org
    Subject: IPP> RE: IFX> New data types [for long text & octetString for
    IPP WG a genda]

    All:

    This "SetOf" solution comes across to me as a "hack." I would prefer to
    have a
    datatype that meets our needs for IPP Fax (which won't work with existing
    implementations anyway) rather than create a "Rube Goldberg" one from parts
    of
    others.

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    **********************************************

    "Hastings, Tom N" <hastings%cp10.es.xerox.com@interlock.lexmark.com> on
    03/08/2001 07:24:08 PM

    To: gsonger%netreon.com@interlock.lexmark.com
    cc: pmoore%netreon.com@interlock.lexmark.com,
          ifx%pwg.org@interlock.lexmark.com, ipp%pwg.org@interlock.lexmark.com
    (bcc:
          Don Wright/Lex/Lexmark)
    Subject: RE: IFX> New data types [for long text & octetString for IPP WG a
          genda]

    Yes, for most 1setOf xxx attributes that order isn't important. However for
    the "three musketeers", order is important (at least they have to have the
    same order). In RFC 2922 see the definitions of:

    4.4.1 printer-uri-supported (1setOf uri) 103
    4.4.2 uri-authentication-supported (1setOf type2 keyword) 104
    4.4.3 uri-security-supported (1setOf type2 keyword) 104

    So I think we have the case that 1setOf order isn't important unless the
    definition of the attribute says otherwise.

    Does that change you preference in this matter?

    Thanks,
    Tom

    -----Original Message-----
    From: gsonger@netreon.com [mailto:gsonger@netreon.com]
    Sent: Thursday, March 08, 2001 12:29
    To: Hastings, Tom N
    Cc: pmoore@netreon.com; ifx@pwg.org; ipp@pwg.org
    Subject: RE: IFX> New data types [for IPP WG agenda]

    Hi Tom,

    Personally, I prefer having a single octet for the attribute. In all of the
    other cases of (1setOf text(MAX)) the values have been discrete values and
    the
    order of the values was not important. If we were to split the conneg
    string
    across multiple octet strings, then order would be VERY important and we no
    longer have one octet string representing a complete value.

    Gail

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 03/06/2001 11:02:37 AM

    To: Paul Moore/AUCO/US@AUCO
    cc: ifx@pwg.org, ipp@pwg.org (bcc: Gail Songer/AUCO/US)

    Subject: RE: IFX> New data types [for IPP WG agenda]

    Paul and IPP FAXers,

    I wasn't at the Maui meeting (and haven't seen any minutes).

    And I'm sorry not to be at the meeting today.

    However, I question the idea of adding new long data types. I thought it
    made much more sense to make the attributes be (1setOf text(MAX)) and
    (1setOf octetString(MAX)). Then you could have an arbitrary number of 1023
    octet strings. There would be no 32K or 64K limit. We'd never have to add
    new data types. AND MOST IMPORTANT, IPP FAX would be compatible with
    current IPP (which was one of our main goals). Then current Printer
    implementations could support the added features of IPP FAX, but would not
    have to add fundamental mechanisms, such as new data types.

    If you think it is a problem to break up CONNEG strings at arbitrary
    boundaries, and alternative would be to have an IPP FAX Printer attribute
    that is the URL to the conneg text file. Advantages:

    a. The conneg file could also be any length.
    b. The conneg file could be on another server.
    c. A client implementation that also supports Internet FAX would be dealing
    with the same CONNEG text strings as a unit that come back from the server.

    As Paul suggests, this should be also discussed at the IPP WG meeting,
    tommorrow, March 7.

    Tom

    -----Original Message-----
    From: pmoore@netreon.com [mailto:pmoore@netreon.com]
    Sent: Monday, January 29, 2001 09:42
    To: ipp@pwg.org
    Cc: ifx@pwg.org
    Subject: IFX> New data types

    Fellow IPPers,

    In the IPP Fax meeting in Maui (1/26/01) we decided that we needed two new
    data
    types to deal with large lumps of data.

    BigText. This is just like Text except that it is up to 65535 bytes long
    BigOctetString. This is just like OctetString except it is up to 65535 bytes
    long.

    BigText is used for vcard representation of users. [Note to ifx attendees -
    this
    does need to be text since it contains localized human readable data - my
    mistake].

    BigOctetString is used for CONNEG data. We are alos considering using it for
    carrying digital certificates.

    We considered several alternatives but this seemed the cleanest solution.

    Can I therefore ask that this be a topic for your next meeting so that you
    can
    bless this change (or not of course!)

    THnaks

    Paul Moore
    IPP Fax Chair



    This archive was generated by hypermail 2b29 : Fri Mar 09 2001 - 12:47:49 EST