Content Packaging Meeting 2010-06-02
Jump to navigation
Jump to search
Notes from 'Content Packaging' Workgroup
Date: June 2, 2010
Time: 1pm-2pm
Leader: David McCallie
Attendees: Lin Wan, Didi Davis, David McCallie, Vidit Saxena, Vassil Peytchev, John Moehrke, Paul Saxman, Karen Witting, Eric Heflin, Arien Malec, Jackie Key
Actions for this Week
Agenda
· Review of last week’s action items
· Discussion - Suggestion is that we review any pressing content/encoding issues that have come up from the concrete implementation groups. If there are no issues that need group discussion, then we will adjourn so that teams can continue to work on concrete implementations for next week.
· Next Steps
Notes
· Action #21 – Keith may not have completed this action, Arien will post a link to the HISTP C80 page
Comment from David McCallie
· Propose to open meeting for questions based on the concrete implementations
· SMTP Update
o Treating content encoding as though it’s ordinary email
Comment from Arien Malec
· REST Update
o Using internet message format for content container
o REST implementations are ignoring the content piece and dealing primarily with required headers
o Wrestling with how to pull out content package for signing and encryption
o Going down path of implementing S/MIME security model
o Would be worthwhile to define a standard way to pull out the subject header, as it may contain PHI
· We can tell people not to put certain things in the subject header, but someone may type PHI into a subject field if they’re using a normal email client
· John Moehrke
o Believe this is a concrete model discussion
Comment from David McCallie
· Subject field is valuable to certain users
· How to protect PHI in a subject header is an issue that we’ll have to re-visit depending on the chosen concrete model
· If you’re using a non-email client, PHI could go into the manifest
· John Moehrke
o If you’re using XDM, could go into the manifest
Comment from Jackie Key
· Is there anything the WG should present at next week’s face-to-face meeting?
· David McCallie
o Each of the concrete implementation teams will address content packaging
Comment from Lin Wan
· Are the content package metadata and manifest going to be required?
· John Moehrke
o We reserve the right to re-examine the metadata model in the future, for now we’re just providing guidance to the concrete implementations
· David McCallie
o Only addressing would be required
· John Moehrke
o Low-bar metadata allows a human to read the content and understand what to do
o If you have a single document, it wouldn’t be so hard for a human to handle, but multiple documents might be challenging
o May want to revisit after implementation is chosen
· Lin Wan
o Is the manifest document a required part of the spec? It’s not mentioned in the spec currently
· David McCallie
o Specification is out of date, it should be updated
· John Moehrke
o Should link to message thread into the content metadata section of the specification
o There is a discussion thread on the wiki about what’s happening inside content and use of the manifest
o John will post a link to the discussion thread regarding manifest use in the content metadata section of the specification
· Arien Malec
o Specification calls for multi-part encrypted as the encrypted data type, which is incorrect if we go with the S/MIME (which has a different content type)
o John will remove the multi-part encrypted data type from the Content Container Specification
· David McCallie
o May need to clarify what happens when agent applies encryption at the HISP
· Lin Wan
o Are the metadata that John documented desired?
· John Moehrke
o We can decide this after next week
Comment from David McCallie
· We’ll fine tune the specification to match the chosen implementation
· As John updates the specification on the wiki, be sure to note the date updated
Comment from Arien Malec
· If we change the content container spec, could impact concrete implementations
· David McCallie
o Probably not a practical issue
· Arien Malec
o When John removes statement about multi-part encryption, he should note that encryption and signatures are as per S&T WG decisions
Notes from 'Content Packaging' Workgroup
Date: June 2, 2010
Time: 1pm-2pm
Leader: David McCallie
Attendees: Lin Wan, Didi Davis, David McCallie, Vidit Saxena, Vassil Peytchev, John Moehrke, Paul Saxman, Karen Witting, Eric Heflin, Arien Malec, Jackie Key
Actions for this Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 22 |
6/2/2010 |
Post a link to the discussion thread regarding manifest use in the content metadata section of the specification |
Open |
John Moehrke |
6/4/2010 |
| 23 |
6/2/2010 |
Remove the multi-part encrypted data type from the Content Container Specification |
Open |
John Moehrke |
6/4/2010 |
Actions from Last Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 21 |
5/26/2010 |
Post a comment to the content packaging wiki page linking to HITSP C80 |
Closed |
Keith Boone |
6/1/2010 |
· Review of last week’s action items
· Discussion - Suggestion is that we review any pressing content/encoding issues that have come up from the concrete implementation groups. If there are no issues that need group discussion, then we will adjourn so that teams can continue to work on concrete implementations for next week.
· Next Steps
Notes
· Action #21 – Keith may not have completed this action, Arien will post a link to the HISTP C80 page
Comment from David McCallie
· Propose to open meeting for questions based on the concrete implementations
· SMTP Update
o Treating content encoding as though it’s ordinary email
Comment from Arien Malec
· REST Update
o Using internet message format for content container
o REST implementations are ignoring the content piece and dealing primarily with required headers
o Wrestling with how to pull out content package for signing and encryption
o Going down path of implementing S/MIME security model
o Would be worthwhile to define a standard way to pull out the subject header, as it may contain PHI
· We can tell people not to put certain things in the subject header, but someone may type PHI into a subject field if they’re using a normal email client
· John Moehrke
o Believe this is a concrete model discussion
Comment from David McCallie
· Subject field is valuable to certain users
· How to protect PHI in a subject header is an issue that we’ll have to re-visit depending on the chosen concrete model
· If you’re using a non-email client, PHI could go into the manifest
· John Moehrke
o If you’re using XDM, could go into the manifest
Comment from Jackie Key
· Is there anything the WG should present at next week’s face-to-face meeting?
· David McCallie
o Each of the concrete implementation teams will address content packaging
Comment from Lin Wan
· Are the content package metadata and manifest going to be required?
· John Moehrke
o We reserve the right to re-examine the metadata model in the future, for now we’re just providing guidance to the concrete implementations
· David McCallie
o Only addressing would be required
· John Moehrke
o Low-bar metadata allows a human to read the content and understand what to do
o If you have a single document, it wouldn’t be so hard for a human to handle, but multiple documents might be challenging
o May want to revisit after implementation is chosen
· Lin Wan
o Is the manifest document a required part of the spec? It’s not mentioned in the spec currently
· David McCallie
o Specification is out of date, it should be updated
· John Moehrke
o Should link to message thread into the content metadata section of the specification
o There is a discussion thread on the wiki about what’s happening inside content and use of the manifest
o John will post a link to the discussion thread regarding manifest use in the content metadata section of the specification
· Arien Malec
o Specification calls for multi-part encrypted as the encrypted data type, which is incorrect if we go with the S/MIME (which has a different content type)
o John will remove the multi-part encrypted data type from the Content Container Specification
· David McCallie
o May need to clarify what happens when agent applies encryption at the HISP
· Lin Wan
o Are the metadata that John documented desired?
· John Moehrke
o We can decide this after next week
Comment from David McCallie
· We’ll fine tune the specification to match the chosen implementation
· As John updates the specification on the wiki, be sure to note the date updated
Comment from Arien Malec
· If we change the content container spec, could impact concrete implementations
· David McCallie
o Probably not a practical issue
· Arien Malec
o When John removes statement about multi-part encryption, he should note that encryption and signatures are as per S&T WG decisions