[IPP] Proposed errata for rfc3998

[IPP] Proposed errata for rfc3998

Zehler, Peter Peter.Zehler at xerox.com
Wed Nov 16 18:18:48 UTC 2011


Mike,

I can live with #3.  I see no reason to keep
"original-requesting-user-name" around as a job attribute.   I believe
the  updates below represent #3.

 

Original:

10.8.2.  original-requesting-user-name (name(MAX)) Operation and Job

        Description Attribute

 

   The operation attribute containing the user name of the original

   user; i.e., corresponding to the "requesting-user-name" operation

   attribute (see [RFC2911], section 3.2.1.1) that the original client

   supplied to the first Printer object.  The Printer copies the

   "original-requesting-user-name" operation attribute to the

   corresponding Job Description attribute.

 

Corrected:

10.8.2.  original-requesting-user-name (name(MAX)) Operation Attribute

 

   The operation attribute containing the user name of the original

   user; i.e., corresponding to the "job-originating-user-name" Job

   attribute (see [RFC2911], section 4.3.6) that identifies the Job

   owner on the first Printer object.  The Printer copies the

   "original-requesting-user-name" operation attribute to the

   "job-originating-user-name" Job Description attribute.

 

 

Original:

10.8.4.  job-originating-user-name (name(MAX)) Job Description Attribute

         - Additional Semantics

 

   The "job-originating-user-name" Job Description attribute (see

   [RFC2911], section 4.3.6) remains as the authenticated original user,

   not the parent Printer's authenticated host, and is forwarded by each

   client without changing the value.

 

Corrected:

10.8.4.  job-originating-user-name (name(MAX)) Job Description Attribute

         - Additional Semantics

 

   The "job-originating-user-name" Job Description attribute (see

   [RFC2911], section 4.3.6) remains as the authenticated original user,

   not the parent Printer's authenticated host, and is forwarded by each

   client in the "original-requesting-user-name" operation attribute 

   without changing the value.

 

 

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 

 

From: Michael Sweet [mailto:msweet at apple.com] 
Sent: Wednesday, November 16, 2011 12:55 PM
To: Zehler, Peter
Cc: ipp at pwg.org
Subject: Re: [IPP] Proposed errata for rfc3998

 

Pete,

 

My point about forwarding is that the mechanism for authenticating the
original-requesting-user-name and job-originating-user-name values over
IPP is undefined. How/why do the child printers implicitly trust
everything that is sent to them from the parent printer?

 

But again, the current wording makes original-requesting-user-name and
job-originating-user-name distinctly different:
original-requesting-user-name is the value that was supplied by the
client while job-originating-user-name is the most authenticated name.
Your proposed change would effectively make them the same, in which case
we should:

 

1. Remove forwarding of job-originating-user-name entirely,

2. Delete original-requesting-user-name entirely, or

3. Make original-requesting-user-name exclusively an operation attribute
and use it to pass the forwarded job-originating-user-name value in the
fan-out case (this would, IMHO, be the sanest approach).

 

On Nov 16, 2011, at 9:23 AM, Zehler, Peter wrote:

	Mike,

	 

	The semantics are limited to Job forwarding systems of printers
(i.e. IPP Fan out and fan in).  On the first system the Job's
"original-job-requesting-user-name" and "job-originating-user-name" are
populated with the same value.  Per rfc2911 that value is the most
authenticated printable name that it can obtain from the authentication
service over which the IPP operation was received.  Only if such is not
available, does the Printer object use the value supplied by the client
in the "requesting-user-name".  On the next hop is where things diverge.
The upstream printer uses its own identity  in  the
"requesting-user-name" operational attribute.  It also passes along the
"original-requesting-user-name" as an operational attribute.  The
downstream printer uses the "requesting-user-name", or the identity
obtained from a trusted protocol layer, to insure the request is from a
configured upstream printer.  The downstream printer then copies over
the "original-job-requesting-user-name" operational attribute to the job
object AND to the job object's "job-originating-user-name".  In other
words the child job is owned by the initial submitting user throughout
the chain and not by the immediate parent (i.e. IPP Printers).

	 

	Pete

	 

	 

	Peter Zehler
	
	Xerox Research Center Webster
	Email: Peter.Zehler at Xerox.com
	Voice: (585) 265-8755
	FAX: (585) 265-7441
	US Mail: Peter Zehler
	Xerox Corp.
	800 Phillips Rd.
	M/S 128-25E
	Webster NY, 14580-9701

	 

	From: Michael Sweet [mailto:msweet at apple.com] 
	Sent: Wednesday, November 16, 2011 10:47 AM
	To: Zehler, Peter
	Cc: ipp at pwg.org
	Subject: Re: [IPP] Proposed errata for rfc3998

	 

	Pete,

	 

	If we make this change, then what is the difference between
original-requesting-user-name and job-originating-user-name?

	 

	Section 10.8.4 (re)defines job-originating-user-name as the
authenticated original user and whose value is supposed to be forwarded
by each client unchanged... (something I am not 100% happy with since
there is no provision for it in an IPP job submission)

	 

	Seems like the original intent was for
original-requesting-user-name to be the unauthenticated value.

	 

	(and now I go off to add some text for this to JPS3 for
job-originating-user-uri...)

	 

	On Nov 16, 2011, at 3:17 AM, Zehler, Peter wrote:

	
	
	
	

	Please substitute "section 10.8.3 of rfc3998" for "section
10.8.8 of rfc3998" below.

	 

	 

	 

	Peter Zehler
	
	Xerox Research Center Webster
	Email: Peter.Zehler at Xerox.com
	Voice: (585) 265-8755
	FAX: (585) 265-7441
	US Mail: Peter Zehler
	Xerox Corp.
	800 Phillips Rd.
	M/S 128-25E
	Webster NY, 14580-9701

	 

	From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf
Of Zehler, Peter
	Sent: Wednesday, November 16, 2011 6:13 AM
	To: IPP at pwg.org
	Subject: [IPP] Proposed errata for rfc3998

	 

	All,

	 

	Section 10.8.2 covering "original-requesting-user-name" is a bit
misleading.  The issue is that the Job owner is not always the same as
the  "requesting-user-name".   When forwarding jobs from one printer to
another the "original-requesting-user-name" is the most authenticated
printable name that can be obtained.  As stated in section 10.8.8 of
rfc3998:  "The "job-originating-user-name" Job Description attribute
(see [RFC2911], section 4.3.6) remains as the authenticated original
user".  This is inconsistent with section 10.8.2 as currently written.
Below is my proposed change to section 10.8.2.

	 

	Original:

	10.8.2.  original-requesting-user-name (name(MAX)) Operation and
Job

	        Description Attribute

	 

	   The operation attribute containing the user name of the
original

	   user; i.e., corresponding to the "requesting-user-name"
operation

	   attribute (see [RFC2911], section 3.2.1.1) that the original
client

	   supplied to the first Printer object.  The Printer copies the

	   "original-requesting-user-name" operation attribute to the

	   corresponding Job Description attribute.

	 

	Corrected:

	10.8.2.  original-requesting-user-name (name(MAX)) Operation and
Job

	        Description Attribute

	 

	   The operation attribute containing the user name of the
original

	   user; i.e., corresponding to the "job-originating-user-name"
Job

	   attribute (see [RFC2911], section 4.3.6) that identifies the
Job

	   owner on the first Printer object.  The Printer copies the

	   "original-requesting-user-name" operation attribute to the

	   corresponding Job Description attribute.

	 

	 

	Peter Zehler
	
	Xerox Research Center Webster
	Email: Peter.Zehler at Xerox.com <mailto:Peter.Zehler at Xerox.com> 
	Voice: (585) 265-8755
	FAX: (585) 265-7441
	US Mail: Peter Zehler
	Xerox Corp.
	800 Phillips Rd.
	M/S 128-25E
	Webster NY, 14580-9701

	 

	
	-- 
	This message has been scanned for viruses and 
	dangerous content by MailScanner <http://www.mailscanner.info/>
, and is 
	believed to be clean.

	
	-- 
	This message has been scanned for viruses and 
	dangerous content by MailScanner <http://www.mailscanner.info/>
, and is 
	believed to be clean.
_______________________________________________
	ipp mailing list
	ipp at pwg.org
	https://www.pwg.org/mailman/listinfo/ipp

	 

	
________________________________________________________________________

	Michael Sweet, Senior Printing System Engineer, PWG Chair

	 

	 

	
	
	
	

	 

 

________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20111116/a012333d/attachment-0001.html>


More information about the ipp mailing list