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 : Thu Aug 31 2000 - 13:54:00 EDT