Your not butting in.
See my replies preceded by TH>
Thanks for the comments.
Tom
-----Original Message-----
From: Mike Bartman [mailto:bartman@process.com]
Sent: Wednesday, September 13, 2000 12:18
To: 'ipp@pwg.org'
Subject: RE: IPP> REG - Proposal for "job-recipient-name" Job Template
att ribute
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 "*".
TH> On the other hand, the job-recipient-name was intended to be more of a
user friendly name, not a mail address. So there wouldn't be any regular
pattern that could be defined with a regular expression.
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?
TH> Yes, the client MUST ignore the unrecognized (new) out of band value
'any', but the real problem is what does that client display to the user for
the value of that "xxx-supported" attribute? The hex value for 'any'? That
is why it would be much better to use the existing 'no-value' out-of-band
value. The existing client would display the value 'no-value' in the
language of the user.
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@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.
This archive was generated by hypermail 2b29 : Wed Sep 13 2000 - 23:53:15 EDT