Hi Carl-Uno,
Sadly, Ron was under the impression that the SNMP
mapping had gotten much larger...because the DOCUMENT
got much larger...because I added all the IPP
notification method boilerplate and tables that
Tom asked me to - the ASN.1 got SMALLER between
-03 and -04 (current) versions.
Yes, I have some implementors at Sharp for this
(with the requirement for job traps via SNMP for all
print protocols). At Xerox, I'm not so sure,
but I know of two spooler products and one family of
color printers at Xerox that have been shipping with
the Job Mon MIB v1.0 (RFC 2707) as their job
instrumentation for SNMP-based client applications.
Ron has agreed (when he can) to look at the actual
ASN.1 (about 15% of the current spec). Meanwhile,
I plan to archive the current document and then
strip out everything about IPP and IPP Notifications,
except for one paragraph in the Introduction.
Then, after editing, I plan to issue a new personal
I-D as 'draft-mcdonald-rfc2707bis-traps-00.txt'
(SLP, LDAP, and other WGs have taken to calling
the updates to existing RFCs by the ITU convention
of suffixing the French 'bis' in recent years).
Network printers speak many print protocols. They
all need (at least) job complete notifications. While
we can fix that in-band (or by 'indp:') in IPP, we
can't retrofit the _other_ print protocols. That's
why the Sharp implementors of both print and scan
services are attracted to standard job traps through
the same Job MIB they use for job queue display on
clients.
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc
-----Original Message-----
From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
Sent: Thursday, August 31, 2000 10:45 AM
To: McDonald, Ira; Manros, Carl-Uno B; IETF-IPP
Subject: RE: IPP> NOT - Last word for now on Notification delivery
methods
Ira,
I am sorry, but what became clear in the discussion yesterday, was even Ron
didn't particularly like what we ended up with and stated that he would not
plan to implement it.
So, is there any interest at Sharp or anybody else to actually implement
something like this? Right now we don't seem to have enough support to make
the solution into a standard, independently of how good the technical
solution is.
Carl-Uno
Carl-Uno Manros
Principal Engineer - 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: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Thursday, August 31, 2000 10:06 AM
To: 'Manros, Carl-Uno B'; IETF-IPP
Subject: RE: IPP> NOT - Last word for now on Notification delivery
methods
Hi Carl-Uno,
This is an interesting Catch-22.
The SNMP notifications for IPP was developed in the IPP
WG at the suggestion of the Job Monitoring MIB WG chair
(Ron Bergman), because it has ALWAYS been a requirement
for wider adoption of the Job Monitoring MIB to have
Job traps. Guess I wasted my time doing it under the
wrong auspices.
Cheers,
- Ira McDonald
-----Original Message-----
From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
Sent: Wednesday, August 30, 2000 2:11 PM
To: IETF-IPP
Subject: IPP> NOT - Last word for now on Notification delivery methods
All,
During today's IPP phone conference we went over the current state of the 4
notification drafts one more time.
Here is the outcome of that discussion. If you disapprove, please speak up
right away, otherwise this is the action plan for the IPP WG I will execute
on within a week:
1) mailto: Not enough support for the addition of machine readable
notification. We will hence return to the text that was in the IPP WG Last
Call and send it to the IESG for approval as Proposed Standard RFC.
2) indp: No conflict, we will send the draft to the IESG for approval as
Proposed Standard RFC.
3) snmp: Several people have questioned whether there is enough support to
progress this as an IPP WG document. Will be put on ice, and might just die.
4) ippget: Although the current text seems OK, we have had suggestions that
it should be enhanced for anybody to be interested enough to implement it.
Will be put on ice, and either we get further proposals, and agreements on
how to fix it, or it might just die.
This will focus implementers' attention on the two main delivery methods
that we actually seem to have agreements about, and leave the other two at
the roadside for the time being, maybe forever. For individual contributors
to the "dropped" methods, there is always the option to bring the drafts in
to the IESG as personal drafts for progression as "Informational" or
possibly 'Experimental'. This would only make sense if there was an
implementation behind it.
The other three notification documents that have already been out for IPP WG
Last Call, I also deem to be ready to send to the IESG, after a few
editorial corrections that we spotted during the Last Call period.
It's about time for the IPP WG to get some notification documents out the
door and published as RFCs, we have dragged our feet on this too long
already.
Carl-Uno
Carl-Uno Manros
Principal Engineer - 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
This archive was generated by hypermail 2b29 : Fri Sep 01 2000 - 14:44:21 EDT