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/blueroofmusichttp://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>