IPP> REG - Proposal for "job-recipient-name" Job Template att ribute

IPP> REG - Proposal for "job-recipient-name" Job Template att ribute

IPP> REG - Proposal for "job-recipient-name" Job Template att ribute

Mike Bartman bartman at process.com
Wed Sep 13 15:18:00 EDT 2000


Sorry to butt in, but is there a reason not to allow wildcards and lists?
That would allow validation and some restriction, without requiring that the
printer know every legal recipient.  Something like "*@my.org,
*@my.other.org" would prevent using the printer to spam the net, while still
not restricting internal distributions or requiring a lot of administrative
work.  The "any" spec would then just be "*".

As far as clients being upset at attributes they don't recognize, wasn't
there something in the IPP 1.0 RFCs that said that such things should just
be ignored?

Just ignore me if there's a major reason why this isn't possible or would be
overly problematic.

    -- Mike "back to my IPP client implementation work" Bartman --

> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]

> We could indicate that any value for an "xxx" is acceptable 
> in one of three ways:
> 
> 1. with a new out-of-band 'any' in the "xxx-supported"
> 
> 2. use the existing 'no-value' to mean don't validate if it 
> occurs in an
> "xxx-supported" attribute.
> 
> 3. with a new Printer Description attribute that listed those
> "xxx-supported" attribute name keywords for which no 
> validation was the
> policy.



More information about the Ipp mailing list