We have already stated in the Model document that the server has to keep
track of the security level used when the job was created and ensure that
the same level is used for subsequent operations on the job.
It would be useful if the client also associated security level used with
submitted jobs, but I don't think we need to state that in the standard as
the server will enforce it.
> -----Original Message-----
> From: Wenn, John C [mailto:email@example.com]
> Sent: Wednesday, February 03, 1999 9:58 AM
> To: Ira McDonald; firstname.lastname@example.org
> Subject: RE: IPP> SEC: IPP 1.1 security (phone conference)
> One problem I have with keeping security information in some
> external data
> (directory, SLP, etc.) is what to do about job URI's. The
> job creation has
> some security, and the generated job URI should have the same security
> level. If it's not directly discoverable in the URI, does
> the client and/or
> server have to remember (and enforce) the security level that
> was used on
> job creation?
> > -----Original Message-----
> > From: Ira McDonald [mailto:email@example.com]
> > Sent: Wednesday, February 03, 1999 6:10 AM
> > To: firstname.lastname@example.org; email@example.com
> > Subject: Re: IPP> SEC: IPP 1.1 security (phone conference)
> > Hi John,
> > The IESG has firmly rejected specifying security by alternate
> > scheme names (e.g., 'https:'). The working agreement within
> > the IPP WG is that the security is NOT discoverable by direct
> > examination of the URI, but is found through a directory service
> > (such as LDAP) or service location protocol (such as SLP)
> > by examining the attribute 'uri-security-supported' which is
> > an ordered attribute parallel to the 'printer-uri-supported'
> > attribute.
> > Several IETF-chartered working groups have already been shot
> > down trying to use either 'xxxs:' scheme names or mandatory
> > parameters appended to URI.
> > Embedding security info in URI has gone completely out of
> > favor with the IESG.
> > Also IPP/1.1 systems MUST use 'ipp:' for their URI, per
> > our Area Directors and other IESG members.
> > The SLP 'printer:' template (and its future translation
> > into an LDAP 'printer:' schema) already supports advertising
> > these two IPP Printer object attributes and makes such
> > advertisement MANDATORY.
> > Cheers,
> > - Ira McDonald (outside consultant at Xerox)
> > (editor of SLP 'printer:' template)