[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:24:50 UTC 2014


Hi Mike,

Agreed.

It shouldn't be an opaque blob - the "access-type" should be sufficiently
fine-grained
to allow explicit multi-factor scenarios.

And Pete and I want to state that binary data MUST be sent as straight
"octetString"
and and text data (e.g., password) MUST be sent as UTF-8 (with no trailing
'\0').

The only downside (potentially pretty large for explicit multi-factor
"access-type"
values is rapid loss of interoperability when vendors roll their own name
values
for combinations we didn't anticipate.

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 11:19 AM, Michael Sweet <msweet at apple.com> wrote:

> Ira,
>
> On Jun 16, 2014, at 11:02 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
>
> 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.
>
>
> Then we need to define it and its requirements.
>
> 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.
>
>
> If the auth type defines multiple credentials then those can be provided
> via separate data values in the 1setOf, or using type-specific member
> attributes.  In short, we need to define what the attributes contain, not
> provide a BLOB holder that will become an interoperability nightmare.
>
> Pete and I particularly liked the use of the simple (1setOf
> octetString(MAX)) with auto
> concatenation to support large credentials (X.509 certificates, etc.).
>
>
> That is indeed a simple solution, but let's not make it an opaque blob.
>
>  _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140616/7d8a7cce/attachment.html>


More information about the ipp mailing list