IPP> Final Editing Steps for draft-ietf-ipp-ops-set2

IPP> Final Editing Steps for draft-ietf-ipp-ops-set2

IPP> Final Editing Steps for draft-ietf-ipp-ops-set2

Scott Hollenbeck sah at 428cobrajet.net
Sun Aug 1 10:46:18 EDT 2004


I'll make this change.

-Scott-

> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com] 
> Sent: Sunday, August 01, 2004 10:17 AM
> To: carl at manros.com
> Cc: ipp at pwg.org; Scott Hollenbeck
> Subject: Re: IPP> Final Editing Steps for draft-ietf-ipp-ops-set2
> 
> 
> carl at manros.com wrote:
> > Scott,
> > 
> > I don't see any harm in changing the text as you have suggested.
> > 
> > Objections from anybody else on the DL or we are done, not 
> only with 
> > this documents, but with all the original work items of the WG?
> 
> The only nit I have is that the wording seems to indicate that an
> implementation that allows different security policies is no
> longer conformant.
> 
> I propose changing the "require" to "support" in the following
> sentence:
> 
>      Therefore, IPP Printer implementations MUST *support* both
>      successful certificate-based TLS [RFC2246] client
>      authentication and successful operator/administrator
>      authorization (see [RFC2911] sections 5.2.7 and 8 and [RFC2910])
>      to perform the administrative operations defined in this 
> document.
> 
> I think this makes the intent clear: all IPP implementations must at
> least support TLS+authentication if they provide admin operations,
> but it does not rule out the use of alternate mechanisms which
> provide equivalent security.
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products           mike at easysw dot com
> Printing Software for UNIX                       http://www.easysw.com
> 




More information about the Ipp mailing list