The TLS/SSL encapsulation details should be
included in the model document, so our security
negotiation requirements are transport-independent.
HTTP-specific security mechanisms should be
discussed in the protocol document, with appropriate
references to the model document.
These additions will probably not make it into the
working group last call, but definitely into the IETF
last call well in advance of the December plenary.
There should be no delays in going to proposed, unless
valid negative comments are received during last call.
Randy
Carl-Uno Manros wrote:
>> Randy,
>> This is probably a good idea. It would have been an even better
> idea if you had come up with it a month or so ago...
>> Could you try to explain to us what the impact would be of this
> new document you plan to write.
>> 1) Would it impact anything in our current Model and Protocol
> documents?
>> 2) Would the new negotiation mechanism be mandatory for all
> IPP clients and servers?
>> 3) Will this hold up our current plans for progressing the Model
> and Protocol documents?
>> I think we all need quick answers to these questions.
>> Thanks,
>> Carl-Uno
>> At 12:28 AM 11/1/97 -0800, you wrote:
> >As an action item from the Boulder meeting, I am preparing a
> >proposal document that addresses the order of operations for
> >negotiating security. This document also discusses, in part,
> >the use of URLs to designate security. A number of outside
> >parties involved with security (TLS working group and others)
> >will be reviewing this short document prior to distribution to
> >the IPP working gruop at large. This is in order to save the
> >IPP WG time reviewing and trying to understand something that
> >is technically inaccurate. Carl Kugler at IBM has also
> >volunteered to help review and verify a security
> >negotitation proposal for IPP.
> >
> >One of the ideas expressed in this document is that the
> >working group does not have to explicitly mandate the use
> >of HTTPS for a security scheme.
> >
> >I will try to have this document out late next week.
> >
> >Randy
> >
> >
> >Carl-Uno Manros wrote:
> >>
> >> Bob,
> >>
> >> The decision to require SSL3 framing has a number of consequences which
> >> needs to be reflected in the Protocol document.
> >>
> >> Where you speak about Encoding of Transport Layer (lines 350 - 357), you
> >> now need to say that we are using the combination of SSL3/HTTP. The default
> >> port for this is 443 (rather than 80), and the scheme for SSL3/HTTP is:
> >> https (rather than http). All Printer-URI and Job-URIs will now start with
> >> "https://"> >>
> >> Hope this reaches you in time to get these changes in.
> >>
> >> Scott may need to check for similar changes in the Model document.
> >>
> >> Carl-Uno
> >> Carl-Uno Manros
> >> Principal Engineer - Advanced Printing Standards - 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> >
> >