[IPP] Fwd: IPP Scan operational attribute

[IPP] Fwd: IPP Scan operational attribute

[IPP] Fwd: IPP Scan operational attribute

Ira McDonald blueroofmusic at gmail.com
Mon Jun 16 15:02:50 UTC 2014


Hi Mike,

The reason for some sparse syntax was to support Pete's use case (over the
phone)
of wanting two or more credentials for the *same* destination (i.e.,
multi-factor auth is
in use).  This is a critically important real-world use case.

With the straight parallel 1setOf approach, there has to be a nested
collection to hold
the auth-type, auth-data, etc. for each credential for one destination -
ugly and fragile.

Pete and I particularly liked the use of the simple (1setOf
octetString(MAX)) with auto
concatenation to support large credentials (X.509 certificates, etc.).

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Mon, Jun 16, 2014 at 7:45 AM, Michael Sweet <msweet at apple.com> wrote:

> Ira,
>
> I'm not a big fan of this proposal - I'd prefer the parallel 1setOf that
> we typically use in IPP rather than invent a sparse syntax, particularly
> when the most common use case is a single destination (and the second most
> common is probably a list of email recipients that won't need this...)
>
> Also, if we want to generalize this in the future, perhaps prefix the
> member attributes with "access-" instead of "destination-", with the
> operation attribute being "destination-accesses (1setOf collection)".  That
> would make it:
>
>     Operation Attributes:
>
>     destination-accesses (1setOf collection)
>         access-data (1setOf octetString(MAX))
>         access-type (type3 keyword | name)
>         access-user-name (name(MAX))
>
>
>     Printer Description Attributes:
>
>     access-type-supported (1setOf type3 keyword | name)
>     destination-accesses-supported (1setOf type2 keyword)
>         (required values 'access-data', 'access-type', and
> 'access-user-type' if supported)
>
> For the access-data member attribute, I wouldn't hardcode it to be
> concatenation of values, since there are auth methods that require multiple
> "passwords", but rather define it for each access-type value.
>
> ....
>
> (Future for Print-URI/Send-URI)
>
>     Operation Attribute:
>
>     document-access (collection)
>
>
>     Printer Description Attribures:
>
>     document-access-supported (1setOf type2 keyword)
>         (required values 'access-data', 'access-type', and
> 'access-user-type' if supported)
>
>
> On Jun 15, 2014, at 6:21 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>
> [forwarding to IPP WG list for our Scan discussion on Monday 16 June]
>
> ---------- Forwarded message ----------
> From: Ira McDonald <blueroofmusic at gmail.com>
> Date: Fri, Jun 13, 2014 at 5:22 PM
> Subject: Re: IPP Scan operational attribute
> To: "Zehler, Peter" <Peter.Zehler at xerox.com>, Ira McDonald <
> blueroofmusic at gmail.com>
>
>
> Hi Pete,
>
> So here's a fragment of IPP stuff for the operation attribute
> that can be sparse (i.e., does NOT have to be parallel to the
> "destinations" array)
>
> destination-acceses (1setOf destination-access)
>
> destination-access (collection)
> - member attributes below
>
> destination-numbers (1setOf Integer)
> - required to supply in every row
> - ordinals of rows in "destinations" Job attribute
> - out-of-range ordinal is a fatal Job submission error
>
> destination-user-name (name(MAX))
> - optional to supply in a given row
> - for username/password authentication
>
> destination-auth-type (type3 keyword | name)
> - required to supply in every row
>  - taken from Joe's list with extensions
> - type3 to allow ease-of-extensions (w/out new IPP spec)
>
> destination-auth-data (1setOf octetString(MAX))
> - required to supply in every row
> - binary or UTF-8 text
> - multiple values are concatenated
> - solves the large attribute problem w/out a new datatype
>
> WDYT?
>
> Cheers,
> - Ira
>
>
>
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic at gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
> On Fri, Jun 13, 2014 at 12:24 PM, Zehler, Peter <Peter.Zehler at xerox.com>
> wrote:
>
>>  Ira,
>>
>>
>>
>> As you know I need to add an operational attribute to IPP Scan that
>> contains the information necessary for a Scan Service to store a document
>> at a specified location.  I imagine it would contain items like access
>> tokens or even (yuk) username/password.  The operational attribute will be
>> a parallel collection to IPP Scan’s destinations collection.  In the
>> Imaging Device Security Identification, Authentication and Authorization
>> specification the UserIdentificationType looks close to what I need.  On
>> the wire I do not think I need the UserUuid and I’ll need a
>> username/password.
>>
>>
>>
>> Any idea what I should be using and where I might obtain the detailed
>> definition?
>>
>>
>>
>> Pete
>>
>>
>>
>>
>>
>> Peter Zehler
>>
>> <image001.png>
>> Email: Peter.Zehler at Xerox.com
>> Office: +1 (585) 265-8755
>>
>> Mobile: +1 (585) 329-9508
>> FAX: +1 (585) 265-7441
>> US Mail: Peter Zehler
>> Palo Alto Research Center Incorporated
>> 800 Phillips Rd.
>> M/S 128-25E
>> Webster NY, 14580-9701
>>
>>
>>
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
>  _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140616/2a601af2/attachment.html>


More information about the ipp mailing list