an d the killer things is that 1setof's are not ordered.
"Manros, Carl-Uno B" <cmanros@cp10.es.xerox.com> on 03/09/2001 09:46:57 AM
To: "'don@lexmark.com'" <don@lexmark.com>, "Hastings, Tom N"
<hastings@cp10.es.xerox.com>
cc: Gail Songer/AUCO/US@AUCO, Paul Moore/AUCO/US@AUCO, ifx@pwg.org,
ipp@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@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 - 14:17:30 EST