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

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

pmoore at netreon.com pmoore at netreon.com
Fri Mar 9 14:11:40 EST 2001



an d the killer things is that 1setof's are not ordered.




"Manros, Carl-Uno B" <cmanros at cp10.es.xerox.com> on 03/09/2001 09:46:57 AM

To:   "'don at lexmark.com'" <don at lexmark.com>, "Hastings, Tom N"
      <hastings at cp10.es.xerox.com>
cc:   Gail Songer/AUCO/US at AUCO, Paul Moore/AUCO/US at AUCO, ifx at pwg.org,
      ipp at pwg.org

Subject:  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 at cp10.es.xerox.com


-----Original Message-----
From: don at lexmark.com [mailto:don at lexmark.com]
Sent: Friday, March 09, 2001 4:58 AM
To: Hastings, Tom N
Cc: gsonger at netreon.com; pmoore at netreon.com; ifx at pwg.org; ipp at 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 at 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 at interlock.lexmark.com> on
03/08/2001 07:24:08 PM

To:   gsonger%netreon.com at interlock.lexmark.com
cc:   pmoore%netreon.com at interlock.lexmark.com,
      ifx%pwg.org at interlock.lexmark.com, ipp%pwg.org at 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 at netreon.com [mailto:gsonger at netreon.com]
Sent: Thursday, March 08, 2001 12:29
To: Hastings, Tom N
Cc: pmoore at netreon.com; ifx at pwg.org; ipp at 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 at cp10.es.xerox.com> on 03/06/2001 11:02:37 AM

To:   Paul Moore/AUCO/US at AUCO
cc:   ifx at pwg.org, ipp at 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 at netreon.com [mailto:pmoore at netreon.com]
Sent: Monday, January 29, 2001 09:42
To: ipp at pwg.org
Cc: ifx at 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














More information about the Ipp mailing list