I don't believe that anyone has been suggesting that the IPP protocol not
be on the standards track. The only question is timing. We have been
waiting for over a year for approval of version 1.0 and the documents are
still not published as RFCs. Seems that we should at least wait until the
1.0 is completed and the feedback from the Bake-off is resolved before a
"Last Call" is issued.
You seem to imply that the IPP version 1.1 must be published prior to the
commencement of the Fxx project. As long as IPP/v1.1 is published prior
to the submission of Fxx (to the ITU or IETF) there should not be a
problem. This work should be able to proceed in parallel.
Also, any new IPP attributes required for Fxx could be included at this
time. (The addition of attributes is NOT a change to the protocol.) I am
not suggesting that this work be rushed to meet the "panic" deadlines for
IPP, but we should try to coordinate these efforts so as to minimize the
total work for both groups.
Ron Bergman
Dataproducts Corp.
On Tue, 16 Mar 1999, Richard Shockey wrote:
>
> >One area where I perceive urgency is in harmonizing with other standards in
> >formation (like IFAX). Here, however, I would urge IFAX to sample the
> >energy behind IPPv1 and, again, work with us on the actual feasibility and
> >operational characteristics rather than focusing on agency approval as the
> >only valid benchmark of a standard.
>
> Report from Minneapolis...
>
> I think I can speak for the BOF that there is no consensus for looking at
> anything other than a Standards Track [1.1 vs 1.0] work as a baseline for a
> Fxx like protocol (we're trying not to use the Fxx word) . Normative
> references to non-standards track work is a big NO-NO here if you want to
> IESG approvals. The BOF held today outlined a number of charter issues that
> must be addressed as well as a need to re-review other proposals such as
> SMTP SESSION as logical alternatives. Its going to be several months before
> this work is formally chartered by the IETF.
>
> There was consensus today that 6 issues must be addressed by candidate
> protocols.
>
> A .Timely Delivery [not store and forward]
> B .Security
> C. Quality of output
> D. Legal Identity Exchange
> F. Capabilities Exchange
> G. Proof of Delivery
>
> What will happen next is I've got to clean up the charter, get the minutes
> ready, etc.
>
> Since I'm the proposed chair I really can't be the sole author of any of
> the drafts...another big IETF NO-NO.. so I'm going to identify a coauthor
> we will rip the old IPP2IFAX draft apart.
>
> We will also need to identify authors for a formal "IPP as a Document
> Delivery Service" and potentially "IPP Gateway Services" as well.
>
> There was a suggestion by Larry Masinter that such a Goals document be
> merged with RFC2542 the goals and requirements documents for fax, that met
> with considerable consensus so it might be useful to review that document
> by those interested in this work.
>
> Remember that there is a separate list for this discussion topic and the
> IETF way is that the discussion should be reflected on the list even if it
> is held off line from time to time. I am going to bend over backwards to
> satisify the requirements and feelings of the AD's towards this work.
>
> Yes Carl-Uno has his work cut out for him ...but please extend some
> sympathy to me as well if and when when I have to wade into the ITU.
>
>
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey
> Shockey Consulting LLC
> 8045 Big Bend Blvd. Suite 110
> St. Louis, MO 63119
> Voice 314.918.9020
> Fax 314.918.9015
> INTERNET Mail & IFAX : rshockey@ix.netcom.com
> eFAX 815.333.1237
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>