Content Indirection draft-ietf-sip-content-indirect-mech-04

1
Content Indirectiondraft-ietf-sip-content-indirec
t-mech-04

• Dean Willis, Editor
• IETF 60

2
Changes since -03

• Added option for hash of indirected content
• Discussion of trust anchor problem
• TLS for HTTP a MUST IMPLEMENT (https and upgrade
  to TLS)
• Use of ETag for labeling indirected content
• Clarified Optional free-form text in the
  content-description is user-directed, and not to
  be used by programs for deciding what to do with
  or how to decode the body.
• Required target URIs conform to RFC2396

3
Open Issue MIME Expiry

• Draft adds expiration parameter to
  message/external-body
• Do we need this?
• If so, can we do this without updating RFC 2017?
• If so, Editor to confirm with MIME type reviewer

4
Issues Hash option

• Content-Type message/external-body
• access-type"URL"
• expiration"Mon, 24 June 2002 090000 GMT"
• URL"http//www.example.com/the-indir-content
  .au"
• size52723
• hashlkxwxB7JCOXKRSUQ1sgoOhrB3I
• ltCRLFgt
• Open Issue Ok with MIME people?
• Open Issue Need double quotes?

5
Open Issues Multipart

1. How to reject one of many media types? 415
   rejects the whole payload.
2. Describing how that the multiupart/alternative
   content negotiation mechanism interacts with the
   other content negotiation mechanisms available
   (SIP's and potentially the access protocol's)
   would be good. Proposed Remove section 5.10
3. More text on when to use multipart/mixed vs.
   multipart/related for this type of content
   indirection would be useful. If there is no
   change from the base meanings, fine, but a
   pointer to them and a note to that would be
   good.Proposed Remove section 5.10