Hi,
I agree with Mike. Certainly operation attributes are the right place to
pass signatures, credentials, and other security ticket-like info in IPP.
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 Sat, Feb 28, 2015 at 12:57 PM, Michael Sweet <msweet at apple.com> wrote:
> 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.
>> (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...)
>>> > On Feb 8, 2015, at 10:40 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> >
> > 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> >
> >
> > _______________________________________________
> > 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/20150228/6bdbbc55/attachment.html>