IPP> SEC: IPP 1.1 security (phone conference)

IPP> SEC: IPP 1.1 security (phone conference)

IPP> SEC: IPP 1.1 security (phone conference)

Wenn, John C jwenn at cp10.es.xerox.com
Wed Feb 3 12:57:45 EST 1999


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?

/John

> -----Original Message-----
> From: Ira McDonald [mailto:imcdonal at sdsp.mc.xerox.com]
> Sent: Wednesday, February 03, 1999 6:10 AM
> To: ipp at pwg.org; jwenn at cp10.es.xerox.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)
> 



More information about the Ipp mailing list