Skip to main content

A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages
draft-ietf-sip-content-indirect-mech-05

Revision differences

Document history

Date Rev. By Action
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2006-02-20
05 Allison Mankin
Dear RFC Editor,

draft-ietf-sip-content-indirect-mech normatively references

draft-ietf-sipping-app-interaction-framework-02, which has
a normative reference to draft-ietf-sip-gruu.  The SIP WG has
a concern that the latter document …
Dear RFC Editor,

draft-ietf-sip-content-indirect-mech normatively references

draft-ietf-sipping-app-interaction-framework-02, which has
a normative reference to draft-ietf-sip-gruu.  The SIP WG has
a concern that the latter document will be delayed, and we
have realized that the content-indirect's transitive reference
to gruu can be removed, without a technical change.  This will
allow content-indirect to be published at an earlier time
than otherwise, since app-interaction-framework will be
delayed by gruu.

The change needed is:

OLD:
  The UAS MAY advertise alternate access schemes in the schemes
  parameter of the Contact header in the UAS response to the UAC's
  session establishment request (e.g., INVITE, SUBSCRIBE, etc.), as
  described in Application Interaction [11].

NEW:

  The UAS MAY advertise alternate access schemes in the schemes
  parameter of the Contact header in the UAS response to the UAC's
  session establishment request (e.g., INVITE, SUBSCRIBE, etc.), as
  described in RFC 3840 [11].

Change reference 11 to cite RFC 3840.

This is a correct change.  The schemes parameter is actually defined
in RFC 3840 and we missed this being the better reference.

Thanks!

[Tipped off to this by JDR]
2006-02-20
05 Allison Mankin State Change Notice email list have been change to , from ,
2005-08-08
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-08-05
05 Amy Vezza IESG state changed to Approved-announcement sent
2005-08-05
05 Amy Vezza IESG has approved the document
2005-08-05
05 Amy Vezza Closed "Approve" ballot
2005-08-05
05 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-08-01
05 Allison Mankin sam cleared smb discuss
2005-08-01
05 Allison Mankin State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Allison Mankin
2005-01-06
05 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2004-11-05
05 Ted Hardie
[Ballot discuss]
This is much improved.  One remaining worry:  the IANA registry for access-types has
the following parameters:

Access Types
------------

Type        …
[Ballot discuss]
This is much improved.  One remaining worry:  the IANA registry for access-types has
the following parameters:

Access Types
------------

Type          Description     Reference
----          -----------     ---------
FTP                             [RFC2045,RFC2046]
ANON-FTP                                     [RFC2045,RFC2046]
TFTP                                     [RFC2045,RFC2046]
AFS                                     [RFC2045,RFC2046]
LOCAL-FILE                                     [RFC2045,RFC2046]
MAIL-SERVER                                     [RFC2045,RFC2046]
content-id                                                  [RFC1873]

So the URL access type used in 5.4 is not yet registered
This document contains no IANA actions, so I wonder if
we're missing a registration?
2004-10-27
05 (System) New version available: draft-ietf-sip-content-indirect-mech-05.txt
2004-07-20
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-07-20
04 (System) New version available: draft-ietf-sip-content-indirect-mech-04.txt
2004-07-15
05 Allison Mankin Waiting for a rev shepherded by Dean
2004-07-15
05 Allison Mankin Note field has been cleared by Allison Mankin
2004-01-08
05 Amy Vezza Removed from agenda for telechat - 2004-01-08 by Amy Vezza
2004-01-08
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-01-08
05 Amy Vezza
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Also need note to split refs, add missing IANA considerations  (this …
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Also need note to split refs, add missing IANA considerations  (this can probably be a section stating there are no IANA actions, based on review).  Patrik looked in on this, but there could be Apps review points to be surfaced.' added by Amy Vezza
2004-01-08
05 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Amy Vezza
2004-01-08
05 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for Ned Freed by Ned Freed
2004-01-08
05 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-01-08
05 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-01-08
05 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2004-01-08
05 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen
2004-01-08
05 Bert Wijnen
[Ballot comment]
Editorial comments:
- refs need to be split
- volcano and nwt.com need to be changed to be different domains,
  like example.ORG …
[Ballot comment]
Editorial comments:
- refs need to be split
- volcano and nwt.com need to be changed to be different domains,
  like example.ORG and example.COM
2004-01-08
05 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2004-01-08
05 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson by Jon Peterson
2004-01-07
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-01-07
05 Ted Hardie
[Ballot discuss]
First off, let me say that I think the draft is fundamentally sound and that the move to
this mechanism from text/uri-list is …
[Ballot discuss]
First off, let me say that I think the draft is fundamentally sound and that the move to
this mechanism from text/uri-list is a good idea.  I fully expect my eventual position
on this to be Yes.

There are, however, a couple of issues that may need some further work.  First, RFC2017
has not been updated since the URI spec was 1738.  Though this draft references 2396,
it does not make a clear statement that any URI used must be conformant to 2396 or
its successors (there is one in the works now, and mentioning it as an informative
point might be useful, http://www.ietf.org/internet-drafts/draft-fielding-uri-2396bis-03.txt
is the current version).

Second, the draft notes that HTTP URIs must be supported, but it is not clear how support
for other URI schemes is indicated. If I understood section 5.3 correctly, the recipient must decide
whether to reject external bodies with a 415 prior to having seen the URI in the external body.
Further, the code represents an "unsupported media type"--which is correct if you are rejecting
all external bodies, but not enough information if you are rejecting one particular URI scheme
but still could support the mandatory HTTP URI scheme.  By the way, I believe that the correct
support for TLS here is an upgrade to TLS within HTTP, if required, rather than support of
https. This highlights, though, the more complex error messages which may be required here,
as a failure of the TLS negotiation after the acceptance of the HTTP URI external body is a very
different error condition than rejection of external bodies or failure to support a specific URI
scheme.

This text is in Section 4:

      It MUST be possible to label each URI to identify if and when the
      content referred to by that URI has changed. Applications of this
      mechanism may send the same URI more than once. The intention of
      this requirement is to allow the receiving party to determine if
      the content referenced by the URI has changed without having to
      actually retrieve that content. Example ways the URI could be
      labelled include a sequence number, timestamp, version number,
      etc.

This has a couple of potential misreadings which could be disastrous.  As I
understand it, the author really wants to say:  you must support the Content-id:
specified in Section 5.5, but is not saying that because some URI schemes
might not have a header of that type.  The problem with this way forward, though,
is that the text "label each URI (to say) it has changed" could easily be taken to mean
that the URI itself is varied, rather than some external metadata.  That would open
a whole other can of worms about equivalence that we don't really want to go to.

In this same vein, explaining why strong ETAGs don't make sense here would be
useful if they are not allowed; giving them as an example of this metadata would
be very useful if they are (since the code for them is already widely deployed).

Did the author confirm with the MIME type reviewer that adding an expiration
parameter to external body was okay without formally updating 2017?

This text in 5.10 raises a couple of flags for me:

  If there is a need to send multiple URIs for the purpose of content
  indirection, an appropriate multipart MIME type [5] should be used.
  Each URI should be contained in a single entity. Indirect content may
  be mixed with directly supplied content. This is particularly useful
  with the multipart/alternative MIME type.

First, you now have added yet another content negotiation mechanism
(multipart/alternative).  Describing how that interacts with the other
content negotiation mechanisms available (SIP's and potentially the
access protocol's) would be good.  Second, 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.

I think content-description is mildly underspecified, in that the "optional
free-form text" looks to be an attractive nuisance for middleboxes to
guess the content characteristics of the external body.  I would suggest
adding text to the effect "this may be displayed to the end user but must
not be used by other elements to determine disposition of the body".
2004-01-07
05 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2004-01-06
05 Steven Bellovin
[Ballot discuss]
Why is support for integrity and confidentiality (not privacy, per Russ's comment) not mandatory?  The cost for supporting https should be low, since …
[Ballot discuss]
Why is support for integrity and confidentiality (not privacy, per Russ's comment) not mandatory?  The cost for supporting https should be low, since if I read 3261 correctly support for TLS is already mandatory in SIP.

Beyond that, there's a more subtle problem:  trust anchors.  How does the recipient know what trust anchor (i.e., a certificate authority) is appropriate from the perspective of the sender for this content?  Should it be possible -- or necessary -- to communicate that in the SIP message?  To use an example from the draft, suppose I want to send you a picture that's stored on my company's Web server.  Regardless of whether or not you normally trust the CA that issued my company a certificate, you should trust it here if you trust the SIP message coming from me.  (I'm assuming, of course, that the SIP exchange is protected in such instances.)
2004-01-06
05 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin
2004-01-06
05 Allison Mankin
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Also need note to split refs, add missing IANA considerations  (this …
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Also need note to split refs, add missing IANA considerations  (this can probably be a section stating there are no IANA actions, based on review).  Patrik looked in on this, but there could be Apps review points to be surfaced. ' added by Allison Mankin
2004-01-06
05 Allison Mankin
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Also for split refs, missing IANA considerations  (author believes no IANA …
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Also for split refs, missing IANA considerations  (author believes no IANA actions - this seems right to my review as well).   Patrik looked in on this, but there could be Apps review points to be surfaced. ' added by Allison Mankin
2003-12-29
05 Russ Housley
[Ballot comment]
In the Security Considerations, the document says:

  >For confidentiality, integrity, and authentication, this content
  >indirection mechanism relies on the security mechanisms …
[Ballot comment]
In the Security Considerations, the document says:

  >For confidentiality, integrity, and authentication, this content
  >indirection mechanism relies on the security mechanisms outlined in
  >RFC3261. In particular, the usage of S/MIME as defined in section 23
  >of RFC3261 provides the necessary mechanism to ensure integrity
  >protection and privacy of the indirect content URI and associated
  >parameters.

  Please align with the definitions in RFC 2828 by:
  s/and privacy/and confidentiality/
2003-12-29
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for  by Russ Housley
2003-12-28
05 Allison Mankin Placed on agenda for telechat - 2004-01-08 by Allison Mankin
2003-12-28
05 Allison Mankin State Changes to IESG Evaluation from Waiting for Writeup by Allison Mankin
2003-12-28
05 Allison Mankin
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Author and chairs know they have to provide IANA Considerations section …
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Author and chairs know they have to provide IANA Considerations section even if blank - author believed there were no IANA considerations.  Patrik looked in on this, but I think there are still some Apps review points to be surfaced. ' added by Allison Mankin
2003-12-28
05 Allison Mankin
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Author and chairs know they have to provide IANA Considerations section …
[Note]: 'RFC Editor note for volcano.com and nwt.com to be made into example.com''s.  Author and chairs know they have to provide IANA Considerations section even if blank - author believed there were no IANA considerations.  Patrik looked in on this, but I think there are still some Apps review points to be surfaced. ' added by Allison Mankin
2003-12-28
05 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin
2003-12-28
05 Allison Mankin Ballot has been issued by Allison Mankin
2003-12-28
05 Allison Mankin Created "Approve" ballot
2003-12-28
05 (System) Ballot writeup text was added
2003-12-28
05 (System) Last call text was added
2003-12-28
05 (System) Ballot approval text was added
2003-12-22
05 Allison Mankin State Changes to Waiting for Writeup from Waiting for AD Go-Ahead by Allison Mankin
2003-12-22
05 Allison Mankin
[Note]: 'Review and IETF LC requested 2003-May-13.

IETF LC had no comments, but AD has a few comments to send.' has been cleared by Allison …
[Note]: 'Review and IETF LC requested 2003-May-13.

IETF LC had no comments, but AD has a few comments to send.' has been cleared by Allison Mankin
2003-12-22
05 Allison Mankin There were no IETF LC comments
2003-07-03
05 Allison Mankin State Changes to Waiting for AD Go-Ahead from In Last Call by Mankin, Allison
2003-06-19
05 Jacqueline Hargest Last call sent
2003-06-19
05 Jacqueline Hargest State Changes to In Last Call from Last Call Requested by Hargest, Jacqueline
2003-06-19
05 Allison Mankin State Changes to Last Call Requested from Publication Requested by Mankin, Allison
2003-06-03
03 (System) New version available: draft-ietf-sip-content-indirect-mech-03.txt
2003-05-13
05 Allison Mankin Review and IETF LC requested 2003-May-13.
2003-05-13
05 Allison Mankin Draft Added by Mankin, Allison
2003-03-03
02 (System) New version available: draft-ietf-sip-content-indirect-mech-02.txt
2002-11-21
01 (System) New version available: draft-ietf-sip-content-indirect-mech-01.txt
2002-08-14
00 (System) New version available: draft-ietf-sip-content-indirect-mech-00.txt