[IPP] Document Encryption design notions - some initial thoughts

[IPP] Document Encryption design notions - some initial thoughts

[IPP] Document Encryption design notions - some initial thoughts

Ira McDonald blueroofmusic at gmail.com
Sun Feb 8 15:40:09 UTC 2015


Hi Smith,

Extending "document-format-details" is the preferable approach.  Note that
the JDF to PJT mapping spec has a considerable amount of detail already
mapped to this single IPP collection attribute.  More could be mapped in
future versions of JDF and PJT/Semantic Model.

If you use an exotic MIME type, it will simply be ignored by most MIME
parsers
(and may be "squashed" in transit).  I don't think generic MIME libraries
are a
good place to depend on for your desired functionality.

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 Sun, Feb 8, 2015 at 8:16 AM, Kennedy, Smith (Wireless Architect) <
smith.kennedy at hp.com> wrote:

> Greetings,
>
> After the F2F meetings on Wednesday in El Segundo, I chatted with Joe
> Murdock for a few minutes about the overlap between this and what the IDS
> WG has been up to.  At the moment, for some reason my instinct is to try to
> identify an appropriate MIME Media Type, if one exists, that has a header
> that encapsulates information on the format and any metadata, as well as
> the encrypted payload (if the payload is present).  A document format that
> encapsulates all this information would allow the encrypted document to
> more easily traverse complex print system topologies that may contain
> mixtures of IPP and non-IPP transports, without requiring transcoding of
> the metadata at each hop.
>
> However, IF it is decided that that is an inappropriate direction in which
> to proceed, I was looking in JPS1 (5100.7) and found the
> “document-format-details” attribute, which is a collection of various
> things including attributes to describe a digital signature.  If we were to
> pursue describing this information via IPP attributes, extending this
> attribute’s “members” might be the right place to capture such information.
>
> Please share your thoughts!
>
> Cheers,
> Smith
>
> /**
>     Smith Kennedy
>     Hewlett-Packard Co.
> */
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20150208/cffcd977/attachment.html>


More information about the ipp mailing list