attachment
Hi,<br><br>I agree with Mike. Certainly operation attributes are the right place to<br>pass signatures, credentials, and other security ticket-like info in IPP.<br><br>Cheers,<br>- Ira<br><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div>
<br><div class="gmail_quote">On Sat, Feb 28, 2015 at 12:57 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FWIW, I don't think putting the actual security information in document-format-details is the right approach. *If* the document format was a wrapper containing the document data and security info, then document-format and document-format-details could be used to identify the wrapper used. But I don't think we want to stuff a signature or public key in there.<br>
<br>
(Consider how we have handled the destination-accesses and document-access attributes - they are operation attributes with explicit security requirements that are not "public" Document Description attributes...)<br>
<div><div class="h5"><br>
<br>
> On Feb 8, 2015, at 10:40 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br>
><br>
> Hi Smith,<br>
><br>
> Extending "document-format-details" is the preferable approach. Note that<br>
> the JDF to PJT mapping spec has a considerable amount of detail already<br>
> mapped to this single IPP collection attribute. More could be mapped in<br>
> future versions of JDF and PJT/Semantic Model.<br>
><br>
> If you use an exotic MIME type, it will simply be ignored by most MIME parsers<br>
> (and may be "squashed" in transit). I don't think generic MIME libraries are a<br>
> good place to depend on for your desired functionality.<br>
><br>
> Cheers,<br>
> - Ira<br>
><br>
><br>
> Ira McDonald (Musician / Software Architect)<br>
> Co-Chair - TCG Trusted Mobility Solutions WG<br>
> Chair - Linux Foundation Open Printing WG<br>
> Secretary - IEEE-ISTO Printer Working Group<br>
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>
> IETF Designated Expert - IPP & Printer MIB<br>
> Blue Roof Music / High North Inc<br>
> <a href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br>
> <a href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
> mailto: <a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><br>
> Winter 579 Park Place Saline, MI 48176 <a href="tel:734-944-0094" value="+17349440094">734-944-0094</a><br>
> Summer PO Box 221 Grand Marais, MI 49839 <a href="tel:906-494-2434" value="+19064942434">906-494-2434</a><br>
><br>
><br>
> On Sun, Feb 8, 2015 at 8:16 AM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>> wrote:<br>
> Greetings,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Please share your thoughts!<br>
><br>
> Cheers,<br>
> Smith<br>
><br>
> /**<br>
> Smith Kennedy<br>
> Hewlett-Packard Co.<br>
> */<br>
><br>
><br>
> _______________________________________________<br>
> ipp mailing list<br>
> <a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
> <a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
><br>
><br>
> _______________________________________________<br>
> ipp mailing list<br>
> <a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
> <a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br>
</div></div>_________________________________________________________<br>
Michael Sweet, Senior Printing System Engineer, PWG Chair<br>
<br>
</blockquote></div><br>