Subject: [Sip] New I-D - TOTE - "INFO" on the media path

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2008 19:54:51 -0500

I just submitted a new I-D, which proposes a protocol called TOTE:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt

Basically, TOTE provides the ability to exchange MIME objects of any 
type and "purpose" over a tcp/tls connection established e2e through SDP 
O/A procedures and ICE-tcp. This ties into the INFO disussion; it 
provides the media-plane equivalent of the INFO-events framework.

This draft should arguably go in mmusic but since the INFO debate is 
happening here I submitted it as a -sip.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Sat, 16 Feb 2008 02:41:47 -0600

> happening here I submitted it as a -sip.

Very cool draft.

So with the right MIME object (octet-stream?) and Purpose token 
(iptunnel?), we appear to have an instant answer for the "How do we use 
SIP to set up a VPN connection" problem. Subject to the constraints of 
TCP, of course, which some people don't like. And we have a solution for 
the problem of establishing a device management connection with a device 
that's behind a NAT router.

Seriously: This draft is an exact answer to the question "what is the 
extension model for SIP?" We very much need to come to an agreement on 
that model, and stop extending SIP along three different and 
incompatible axes.

If we choose the model of TOTE, then we might start considering 
deprecation of INFO, MESSAGE, SUBSCRIBE, and NOTIFY. We can also 
probably deprecate MSRP. And PUBLISH, of course. This would really clean 
up the protocol suite, at least for one way of looking at it.

This is a lot to think about. So start thinking!

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 16 Feb 2008 11:32:29 +0100

Hi Jonathan,
 
Interesting draft.
 
One question: is your intention that this would be the ONLY way of using INFO in SIP, or would it be one alternative?
 
The drawback with media planes based solutions is of course that any intermediate interested in the information must have access to the media plane, which may not always be the case.
 
Regards,
 
Christer

________________________________

From: [email-masked] on behalf of Jonathan Rosenberg
Sent: Sat 16/02/2008 01:54
To: IETF SIP List
Subject: [Sip] New I-D - TOTE - "INFO" on the media path

Thanks,
Jonathan R.
http://www.jdrosen.net <http://www.jdrosen.net/>                          PHONE: (408) 902-3084
http://www.cisco.com <http://www.cisco.com/>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 16 Feb 2008 13:42:14 +0100

Hi Jonathan,
 
Chapter 2 of the draft says:
 
"All TOTE implementations support at least the lite versionof Interactive Connectivity Establishment (ICE) for TCP [I-D.ietf-mmusic-ice-tcp]."
 
Now, as far as I know we haven't specified any ICE lite procedures for TCP. ice-tcp-05 (do I read the wrong version?) also says:
 
"Because this specification requires multiple candidates for a media stream, it is not compatible with ICE's lite implementation, and can only be used by full implementations."
 
Now, different alternatives regarding this were discussed in Vancouver, and one of the proposals discussed was to implementing "TCP ICE lite" simply by removing the candidates, use the RFC 4145 "fallback" - and specify that ICE could still be used for UDP based streams.
 
As you said, though, I guess the detailed discussion of the proposal belongs to MMUSIC...
 
Regards,
 
Christer

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Feb 2008 10:15:09 -0500

Christer Holmberg wrote:
> Hi Jonathan,
> 
> Interesting draft.
> 
> One question: is your intention that this would be the ONLY way of
> using INFO in SIP, or would it be one alternative?

It would be one of three alternatives for "application signaling". The 
other two being the existing event framework, and the other being the 
newly proposed info framework.

I am nearly done with a draft which I'll submit shortly that provides 
guidance on selection of a mechanism. I think there are cases for all three.

> 
> The drawback with media planes based solutions is of course that any
> intermediate interested in the information must have access to the
> media plane, which may not always be the case.

Exactly. In those cases you'd use a signaling path solution.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Feb 2008 10:15:54 -0500

The pending ice-tcp draft, which will be out before the non-00 deadline, 
will describe ICE-lite for tcp.

-Jonathan R.

Christer Holmberg wrote:
> "All TOTE implementations support at least the lite versionof
> Interactive Connectivity Establishment (ICE) for TCP
> [I-D.ietf-mmusic-ice-tcp]."
> 
> Now, as far as I know we haven't specified any ICE lite procedures
> for TCP. ice-tcp-05 (do I read the wrong version?) also says:
> 
> "Because this specification requires multiple candidates for a media
> stream, it is not compatible with ICE's lite implementation, and can
> only be used by full implementations."
> 
> Now, different alternatives regarding this were discussed in
> Vancouver, and one of the proposals discussed was to implementing
> "TCP ICE lite" simply by removing the candidates, use the RFC 4145
> "fallback" - and specify that ICE could still be used for UDP based
> streams.
> 
> From: [email-masked] on behalf of Jonathan Rosenberg Sent: Sat
> 16/02/2008 01:54 To: IETF SIP List Subject: [Sip] New I-D - TOTE -
> "INFO" on the media path
> 
> 
> 
> type and "purpose" over a tcp/tls connection established e2e through
> SDP O/A procedures and ICE-tcp. This ties into the INFO disussion; it
> Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D.
> 499 Thornall St. Cisco Fellow
> Edison, NJ 08837 Cisco, Voice Technology Group [email-masked] 
> http://www.jdrosen.net <http://www.jdrosen.net/>
> PHONE: (408) 902-3084 http://www.cisco.com <http://www.cisco.com/> 
> _______________________________________________ Sip mailing list
> http://www.ietf.org/mailman/listinfo/sip This list is for NEW
> development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
> 
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Feb 2008 14:29:41 -0800

Howdy,
	So I read this, then re-read this after having some more coffee,
and I seriously considered re-reading it again after something alcoholic,
just so I could see whether it seemed like a good idea in any of those states.
Since my workplace declines to provide a wet bar, I didn't manage the
last, so there is some chance I'm way off base here.
	First, some comments on the mechanics.  Having a "purpose"
that is not tied to the top level type of the mime type you're transporting
opens you up to a lot of silly states.  If I send you a purpose claiming
something is a pic, but provide text/plain, is it ascii art?  If I claim it is
a pic, but provide application/octet-stream, will the data get fed to
a renderer?  That is, does the MIME type or the purpose handle disposition?
The "Semantics" session seems to indicate it is purpose that governs this:

     Semantics:  Each purpose MUST clearly define what its used for.  T he
      definition must be sufficiently clear to allow an implementation
      to decide whether to render the object, what kind of UI to apply,
      how and where to store the object, how to process it, and so on.

That's going to break how a lot of other things handle MIME object
transport, and incidentally call into question a very basic mechanism
for minting new application protocols currently in favor (that is, using specialty
MIME types to trigger the handling).  I'm not saying it's not a valid design choice,
but it does run counter to the current set of trends.  I also am concerned that in using
the purpose, the design opens things up  to crafted payload attacks. 
	Second, none of the examples seem to show parameters
being included with the MIME types; dealing with those provides a serious
set of problems for interoperability (think of the charset parameters for an
easy example).  Supported MIME types may not be enough to determine
whether you and your intended recipient actually do share enough for
an interoperable transfer.  This is also true with bucket MIME
types (like message/cpim) which can contain other MIME types. 
	I found your description of the session model and the
answerer behavior somewhat unclear, and I'd like some additional
clarification.  In the answerer section, you say:

    An agent receiving an offer with an m=message line including the
   protocol "TOTE" or "TOTES" is being offered the opportunity to set up
   a TOTE session for one or more purposes.  If the agent is capable of
   receiving objects using at least one of the purpose tokens associated
   with the tote session, the agent SHOULD accept the session.  If it
   can receive none of them, it MUST reject the session (by setting the
   port to zero).

The TOTE session described here looks like it is multiplexed for all the original
purposes.  For a receiver to remove one or more purposes from the
original set, do I understand correctly that it needs to tear down the
TOTE session and set up another?  (On a side note, the TOTE vs. TOTES
issue looks to have exactly the same ratholes we've seen before).
	Your draft says:

   An actual TOTE message can
   span several RFC4571 frames; this is analagous in general to reads
   off of a TCP connection - the amount of data read at a time has no
   bearing on the length of the actual message.  As a consequence of
   this, even though RFC4571 has a limit of 64k, there is no constraint
   on the length of a TOTE message.

I assume that this means that a TOTE implementation should not
try to split its messages using any existing MIME facilities for that.
Why not re-use the mechanism of things like message/partial?
It would also be good to describe whether a MIME type like
multipart/alternative SHOULD be split and each alternative listed
in the SDP offer, or whether the multipart/alternative should be
listed.  If the former, the semantics of how to restore the default choice
semantics of multipart/alternative should be described.  If the latter,
how does the receiver know anything about the interal parts' mime types?
 	In other issues, I found the IANA consideration section very
underspecified.   This seriously needs to indicate when a purpose like
"whiteboard" is general and when it is specific to an application.  Having
something that indicates what potential MIME types would be for this
(and a way of updating the registration) would be much better than
the "Description" field you have, and having both would be better still.
The IANA considerations section also needs to re-mention the possibility
of vendor specific purposes, and indicate whether they should conform
to things like the SHOULD limit of 20 characters.  (To put this another
way, your IANA considerations only handle one of the two namespaces,
and should mention the other and describe it as well).  You have
several examples (name, pic, bizcard, whiteboard) in the draft,
but you do not register them.  Why not?
	The Security Considerations don't begin to describe the
issues here, and I assume that would change if this progressed.
I look forward to hearing how the deep-packet inspection industry
enjoys a bi-directional TLS-protected generic MIME tranport that
gets through NATs and Firewalls using relays everyone thought
they were deploying for VoIP.
	On the big picture, I think this is in the muddy middle
in too many ways.  Having an application linked to a specific
transport is pretty well understood.  Having a transfer protocol linked to
very limited application semantics (e.g. FTP) is also pretty well understood.
Having a generic rendezvous mechanism that multiplexes MIME objects
intended for consumption by multiple different applications seems to
run across some pretty rathole-infested ground (head of line blocking
for my camera-control object when I'm sending media to a different
application; MIME disposition ambiguity; interoperability
problems when every vendor chooses their own specific purpose
strings).
	If this is the cure, the disease was much, much worse than
I thought.
	I look forward to my post-work re-read,
					Ted

---

From: Dean Willis <[email-masked]>
Date: Tue, 19 Feb 2008 21:21:29 -0600

>      how and where to store the object, how to process it, and so on.

Well then, none of the way we use MIME in any of the "considered good"  
uses in SIP must make any sense.

For example, with NOTIFY, the body is some sort of MIME object that  
may well have many different possible uses. It's the event type that  
tells us what that specific mime type means in the context of this  
NOTIFY.

Otherwise said, an event package that defines a NOTIFY contain an  
application/octet-stream has to explain what to do with the octet- 
stream.

What does it mean if we get a NOTIFY containing an image/jpeg? Should  
we display it? File it? Turn it into an mjpeg movie? Run a fingerprint  
recognizer on it? Apply steganogarphic analysis to extract the  
watermark? Here, the handling is driven by the event type, not the  
MIME type.

That's the same as a "purpose" in TOTE. Each TOTE purpose would need  
to be documented, and that documentation would need to explain what  
MIME types can be sent for that purpose, and what it means to receive  
such a type in the context of a given purpose.

> the purpose, the design opens things up  to crafted payload attacks.

The whole argument against INFO is that the MIME type itself is  
inadequate to trigger the handling. If it were adequate, we wouldn't  
have had this big fight about INFO for the last n-many years.

Or are you now saying INFO is good and sip-events are BAD?

Did I just wake up in a different quantum universe again? Dang it,  
that always confuses me.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Feb 2008 22:28:03 -0800

>application/octet-stream has to explain what to do with the octet-

But event packages are fairly fully specified, compared to what this
draft seems to propose.  If you have an extremely generic statement
like "pic" and expect to extract semantics beyond that of the top
level image/ mime type, I think you're going to get pretty disappointed.
Now that I am re-reading after having gotten "home" (wink-wink),
maybe I did miss the idea.  If the idea is that the specification of
"pic"  or "name" is at the level of the specification of an event package,
then we are dealing with something else entirely and the draft can
be re-written to express that.  But I would expect, in that case, for each
of the registered purposes to be very carefully specified as to what the
acting application would do with them.  And I suspect pretty much
everything like "name" would have to go.

>such a type in the context of a given purpose.

Again, if the level of specification that is expected is equivalent to event
packages, this has some hope of working.  Look at the IANA considerations
section again, though, and I think you'll see that does not appear to
be required by the current draft.

>Or are you now saying INFO is good and sip-events are BAD?

I'm saying that what the draft appears to be replacing INFO with is as bad
as INFO, as the "purpose" looks to be a mighty low-quality signal for
disposition.  There are some existing, common MIME types which
are bad, no question.  "pic", however, doesn't seem to tell you any better than
image/jpeg whether to display, it file, transform it, examine it for watermarks,
or print out the coupon it contains for a free helicopter ride to
CityWest.    Neither image/jpeg or "pic" is likely to do as you as much
good as one of the application-protocol specific MIME types created with
a disposition in mind, like application/atom+xml .

>Did I just wake up in a different quantum universe again? Dang it,

Permit me to suggest a dram or two of a well-tempered liquid, preferably
after it has been aged in a wood barrel of some kind.  It might not result
in clarity, but that won't bother you nearly as much.

				Ted

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Feb 2008 12:30:48 -0600

On Feb 20, 2008, at 12:28 AM, Ted Hardie wrote:
>
> .  If the idea is that the specification of

Ok, I think I agree with you here. Each "purpose" would need to be  
very clearly specified, at roughly the same level of detail as is  
required for an event package or would be required for an INFO package  
if we were to go that way. And yes, the draft is a bit short on this  
right now.

--
Dean

---

From: [email-masked]
Date: Wed, 20 Feb 2008 16:44:05 -0500

From: Dean Willis <[email-masked]>

   Ok, I think I agree with you here. Each "purpose" would need to be  
   very clearly specified, at roughly the same level of detail as is  
   required for an event package or would be required for an INFO package  
   if we were to go that way.

IMHO the purposes need to be specified in *more* detail than an event
package.  The reason is that an event package is "pull" information,
the meaning of the information is defined by the event-name, but the
requestor is presumed to know *why* it wants the information, that is,
what it intends to do based on that information.  A TOTE object, like
an INFO, is "push" information, and the attached meta-data must
specify not only what the information means, but how the recipient is
expected to act on it.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 22 Feb 2008 19:01:00 -0500

It only gets pushed to the client if the client indicates support for 
it. Thus, the typical flow is:

A->B : "hey, you can send me pic if you want"
B->A : "ok I will"

and I think this is very much like:

A->B : "please send be pic"
B->A : "ok I will"

which is what SIP events is about. In terms of the need to understand 
the semantics of the data, they are identical.

Now, the intended model in TOTE is that there would be two types of 
purpose parameters. Global ones which are standardized, and a vendor 
tree. The global ones require a specification, though it doesnt at the 
moment require standards track. But it does need an RFC. I am happy to 
debate standards track vs. ietf action.

That said, depending on the purpose, I don't think there is that much 
needed in such a spec. For example, for pic, something along the lines 
of "this purpose is meant for picture sharing between users. For 
example, in cases where a user with a cell phone snaps a picture during 
a call and wishes to send it to the other person, or wishes to send an 
existing file on disk. The received picture is normally rendered, 
possibly with user permission, and possibly saved by the recipient. All 
implementations MUST support image/jpg."

I'm not sure that much more is required; we could debate whether 
max-size needs to be dealt with, and that could be done any number of 
ways. The TOTE model would argue that you would do this by having a 
message from recipient to sender, over this TOTE connection, with the 
max size. Indeed, you could also have a message from sender to recipient 
first that indicates an interest in sending a picture right now, 
including picture metadata. This would imply that "pic" is really a 
three way handshake, two of which are some new messages we'd need to 
define (and presumably would be defined by the tote usage). We could 
alternatively send those params through SDP, but that constrains us to 
the O/A 2-way handshake; and as we have seen with things like SRTP, 
having the flexibility of building the protocol without the constraints 
of O/A is highly beneficial. It also means you can add new stuff without 
extending SIP itself.

What TOTE does is it avoids the need for this particular application to 
define how to get connections set up through sip, how to secure them, 
how to do nat traversal for them, how to signal what they are used for, 
how to negotiate them, and so on. It also gives us the ability to share 
connections across applications when it makes sense; this also allows us 
to have very rich multi-app communications in one session without this 
large number of connections.

And so in my mind, it lowers the bar for new applications by providing a 
framework for adding new ones without needing to change SIP, and to have 
the flexibility of engineering the application ideally for its 
particular needs.

-Jonathan R.

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 25 Feb 2008 10:51:50 -0000

[Chris Boulton] BUT then we are just recreating the Control Framework
(http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-sip-control-fr
amework-01.txt) from the MediaCtrl work group - just called a different
name.  I'm not sure why we can't just use that.

Chris.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 25 Feb 2008 09:55:53 -0500

Sweet draft.

I would actually define the session-based IM usage for this first.  It would fix a lot of the NAT traversal issues we can't currently get around with MSRP. (the basic lesson being: don't put IP Addresses/ports in application layer messages when you don't need to)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Rosenberg
> Sent: Friday, February 15, 2008 7:55 PM
> To: IETF SIP List

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Feb 2008 17:07:57 +0200

Hadriel,

would you box block it since it travels along the media path?

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 25 Feb 2008 10:11:48 -0500

Well, looking at draft-ietf-mediactrl-sip-control-framework-01.txt for the first time, I would say one reason is that the TOTE mechanism has a better chance of success in more environments.  At least across SBCs, if that matters to you. (it matters to me, obviously, but not everyone)

Also, TOTE is a lot lighter weight, although I'm sure after a few rounds of drafts with lots of people's inputs it will probably grow to be not far off. :)

-hadriel

> Chris Boulton
> Sent: Monday, February 25, 2008 5:52 AM
> To: Dean Willis; Ted Hardie
> Cc: IETF SIP List
> Subject: Re: [Sip] New I-D - TOTE - "INFO" on the media path
>

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 25 Feb 2008 15:32:03 -0000

Well, looking at draft-ietf-mediactrl-sip-control-framework-01.txt for
the first time, I would say one reason is that the TOTE mechanism has a
better chance of success in more environments.  At least across SBCs, if
that matters to you. (it matters to me, obviously, but not everyone)

[Chris Boulton] Which is exactly why the Control Framework needs
valuable input from RAI experts for the next revision (which is already
planned).  This is certainly an area that 'we'(mediactrl) have flagged
to look at for the next version of the Framework.  I certainly wouldn't
want to see yet another 'parallel fork' (that one is for Dean) in IETF
technology - especially as the Control Framework is the rarest of beasts
in the IETF in that it ACTUALLY has several 'running code'
implementations. 

Also, TOTE is a lot lighter weight, although I'm sure after a few rounds
of drafts with lots of people's inputs it will probably grow to be not
far off. :)

[Chris Boulton] hehehe - that made me smile.  Next you will be telling
me that SIP is a light weight protocol :-).

-hadriel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 11:05:29 -0500

Chris,

Thanks for pointing this out - I hadn't looked at the 
mediactrl-framework before and there is definitely overlap and a 
relationship between it and TOTE.

Here is my analysis on the similarities and differences:

Both of them are about establishing connections between agents through 
an O/A exchange. Mediactrl uses comedia, whereas TOTE uses ICE-tcp. 
ICE-tcp will fall back to comedia when both sides are unnatted.

TOTE, however, provides a layer of demux within the SDP signaling, 
allowing for negotiation of what runs over the channel as part of the 
O/A negotiation. In mediactrl, this is done within the control channel 
itself, by doing a supported kind of exchange over the mediactrl protocol.

TOTE and media-ctrl framework both define a simple message protocol that 
runs over the connection. This is lighter weight in TOTE; its just for 
framing and purpose demux. mediactrl defines specific messages - 
control, report, synch, etc., transactions, response codes.

Mediactrl solves the problem of binding a connection to a dialog by 
defining a SYNC message. TOTE solves this problem by using ICE, which 
provides this correlation as part of its normal operations. Mediactrl 
solves the problem of keepalives using its own keepalive message; TOTE 
uses the ICE keepalive mechanism.

Since TOTE is a bit lower-layer than mediactrl, one model is to think of 
running mediactrl over TOTE. Mediactrl would then be a specific 
"purpose" parameter. When you do this, a bunch of features would get 
removed from mediactrl - all of the SDP stuff, connection establishment, 
synch mechanism. Mediactrl would continue to define the notion of 
control packages, control package negotiation, REPORT, CONTROl, response 
codes, transaction rules, etc.

I think thats a good story - instead of each and every protocol (like 
mediactrl) needing to worry about this lower-layer connection management 
and connectivity stuff, we solve it once, and provide a framework for 
reusing connections across different protocols and applications. So that 
one tcp connection between me and my media server could be used for 
mediactrl messages, streaming commands, picture transmission, etc.

-Jonathan R.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 25 Feb 2008 11:06:21 -0500

Nope.  As I tried to explain a bit in the To/from uri changes draft, it's not that SBCs want to block such things, it's up to the owner of the SBC to decide whether to allow it or not.

-hadriel

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, February 25, 2008 10:08 AM
> To: Hadriel Kaplan
> Cc: Jonathan Rosenberg; IETF SIP List
> > I would actually define the session-based IM usage for this first.  It
> would fix a lot of the NAT traversal issues we can't currently get around
> with MSRP. (the basic lesson being: don't put IP Addresses/ports in
> application layer messages when you don't need to)
> >
> > -hadriel
> >
> >
> >
> SDP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 11:14:26 -0500

> Sweet draft.

Thanks!

> 
> I would actually define the session-based IM usage for this first.
> It would fix a lot of the NAT traversal issues we can't currently get
> around with MSRP. (the basic lesson being: don't put IP
> Addresses/ports in application layer messages when you don't need to)

I thought about that a bunch; I had planned a separate draft on how MSRP 
is different than session-mode IM over TOTE. The million dollar question 
is, what MSRP features would be lost and would we still need them. I've 
convinced myself that the key architectural difference - the use of turn 
for relays rather than an IM-specific relay, causes a very different 
inter-server connection model and has a huge impact on the functionality 
required in the protocol.

That said, I do think TOTE has a really good overall nat/sbc story. Its 
usage of ice-tcp will allow it to work reasonably well (with some amount 
of relaying...) with existing fw/nat. Whether it would work through 
existing SBCs depends a lot on what they do; whether they have the 
ability to pass unknown m-lines or not. However, more importantly, once 
an SBC does support TOTE, it would only need to support it once, and 
then from then on, all tote-based applications would work through the 
resulting connection (of course I have no doubt that SBCs would want to 
do per-purpose blocking/allowing but this becomes an issue of 
configuration and NOT software update; that is what I want to avoid).

-Jonathan R.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 25 Feb 2008 09:33:33 -0800

Jonathan,
	Did you see my messages in this thread?  I raised several
issues with the approach you appear to be outlining again here, and I'm
wondering if you saw them.  To recapitulate just slightly:

The negotiation model appears inadequate to deal with MIME types
with significant parameters, with multipart MIME types, or with
MIME types that have "bucket" semantics (like message/cpim, the
container video types, or the 3ggp bucket mime types). 

Having a dispatch based on purpose without detailed specifications or
reference to specific applications seems to hit a middle ground that's
kind of nobody's sweet spot.  A specific application already has detailed
semantics that go beyond this purpose to actual decisions of whether
to render or store, user permissions needed, sizes accepted, etc;
generalized MIME transfer protocols like SMTP or HTTP already
use a different system for deciding which applications to invoke
when faced with a MIME object, and this forces systems with that
logic to have a parallel track.

The muxing seems liable to head of line blocking unless BEEP-like
channels are introduced.

This seems to re-purpose the deployed TURN servers in ways that
transform them into a generic NAT/Firewall avoidance mechanism
for any MIME type.  You're listing that as a feature.  Isn't there
a risk that security folks will see it as a bug?

				regards,
					Ted

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 13:36:51 -0500

Ted,

I did see your note. Dean had responded, and your response to him, I 
thought, indicated that you were satisfied that having purposes 
specified (which was the intent of the draft) addressed your concerns. 
Sorry for having misunderstood. Some responses below:

> container video types, or the 3ggp bucket mime types). 

OK; this was just a -00. There are two ways to deal with that:

1. add the additional negotiation needed for this as new SDP parameters, or

2. don't bother at all with MIME negotiation as part of SDP for TOTE; 
rather, each purpose would have a protocol to doing the negotiations 
needed to make its functionality work. This avoids needing to do a 
general purpose MIME thing. FOr example, in the case of "pic", we'd 
actually define a little protocol that negotiates pictures sizes and 
supported types. In that applications, buckets and multiparts aren't an 
issue.

I'm inclined towards #2 actually. But note that, I put into TOTE exactly 
the same level of MIME negotiation that SIP itself provides. SO if it is 
grossly inadequate here, so it is there.

> kind of nobody's sweet spot. 

That was never the intent. The IANA considerations section states that 
these require specification.

> A specific application already has detailed

That would seem to argue for pulling the MIME aspects out of TOTE.

> The muxing seems liable to head of line blocking unless BEEP-like

This is discussed; if the purpose requires significant content, set it 
up as a separate session/tcp connection.

> a risk that security folks will see it as a bug?

I think you are getting wrapped up in the MIME parts of this, which is 
not the main point. The main point is that there are lots of cases where 
we need UA to UA communications - see:

http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-use-cases-00.txt

I was trying to provide a common mechanism for addressing those cases 
where we don't want to send all this garbage over SIP - we want it over 
the media plane. Are you objecting to that?

-Jonathan R.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 27 Feb 2008 12:07:18 -0800

>Sorry for having misunderstood. Some responses below:

Sorry for the delay in replying.  Some further questions below.

>grossly inadequate here, so it is there.

I'd be interested in seeing more on how #2 works.  One of my concerns
with "pic", to take one example, is how a very generic purpose like
trading images gets used by applications that want it.  How does a
system know when a pic being sent from one side of the TOTE exchange
to the other is meant as a new user icon, an avatar for a MMORPG, or
a stand-alone picture relevant to some ongoing exchange on a
real time channel?  If there is more interaction than just "purpose"
and mime type, then re-use of this by applications that want the facility
may work.  Otherwise, it seems you are either going to head towards
purposes like "vnd.WoW" that have no generality or you are going
to get what amounts to a least-common-denominator application.
The "I can send you my name" application is not really too compelling.

>up as a separate session/tcp connection.

What you have there now is:

   However, if a purpose represents a
   significant amount of data, such that head-of-line blocking might
   occur between purposes, an agent SHOULD utilize a separate TOTE
   session for that purpose.

I guess this still worries me.  If an application wants to set up a TOTE
connection with an existing peer, I'm guessing it will need to decide
whether to re-use an exiting session or set up a new one.   While it
may have a sense of whether it will have large amounts of data to
send, it doesn't have any idea of the sensitivity to head of line
blocking from the other users of the connection.  That pushes the
decision into the agent which knows something about both.
But that ends up requiring a lot of knowledge of the protocol
usage characteristics of the using application which go beyond
what TOTE will carry on the wire (some uses of "pic" with image/jpeg
are really highly unlikely to cause head of line blocking; others might be a
real clog).

Defaulting to non-muxed connections eliminates that, of course,
but removes one of the benefits you propose.

>the media plane. Are you objecting to that?

A number of your purposes seem pretty far outside the info-use-cases
draft, and the level of generality does raise issues.  Maybe I am
too concerned with the "generic MIME transport" aspects of this,
but I think replacing INFO with a media plane solution that
does not have at least the level of specificity of event packages
is not helpful and may even be harmful.  I'll try to corner you
in Philadelphia to discuss this in person,  especially on your
"little protocol" proposal above.  There may be an opportunity
there.
			regards,

					Ted

Sip mailing list  https://www.ietf.org/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Feb 2008 16:25:07 -0500

inline:

Ted Hardie wrote:

> I'd be interested in seeing more on how #2 works.

Well, I'm thinking on my feet here, but for picture sharing, something 
like this:

A->B INVITE tote session, purpose=pic
B->A 200 OK tote, purpose=pic
A->B ACK

A->B [TOTE] I support jpg, png. Screen resolution here is just 100x200, 
8 bits color.
B->A [TOTE] I support just jpg, but I have a huge screen so up to 
1000x1000 is fine. 24 bits color.

and then later:

A->B [TOTE] Hey I'd like to send a picture, 200x200, jpg, 8 bits color. 
 From the camera. OK?
B  (prompts user, "Joe would like to send you a photo. Accept?". user 
accepts)
B->A [TOTE] yes proceed
A->B [TOTE] sends image
B->A [TOTE] file received

Again, thinking on my feet here.

   One of my concerns
> real time channel? 

I see your concern. I think the main criteria is that, this is used when 
the primary purpose is to render an image to the recipient, and allow 
them the option to save. Since a part of this is rendering you need to 
think about screen sizes, colors and so on to make sure the image is in 
a form that can be processed by the recipient for rendering. So anything 
that needs this - negotiation of picture sizes for immediate rendering - 
could use it. Primary application would presumably be cameras on mobile 
phones.

  If there is more interaction than just "purpose"
> may work.
>  Otherwise, it seems you are either going to head towards

Agreed. No dispute that each purpose needs to be well defined and broad 
enough to be useful and narrow enough to meet the needs of the specific 
use cases well. But thats always the case in engineering.

> whether to re-use an exiting session or set up a new one.  

Right.

> While it
> blocking from the other users of the connection.  

Well there is only one other user, the recipient. But I tend to think 
this is mostly a function of the 'purpose'. You'd put picture share by 
itself, but more control-style functions (i.e., camera control or 
conference controls) could be multiplexed.

That pushes the
> are really highly unlikely to cause head of line blocking; others might be a

So I agree that this kind of dynamic decision is really complicated and 
a static decision based on purpose is much easier.

> draft, and the level of generality does raise issues. 

I think the level of generality in there is EXACTLY the same as the 
INFO-usages. Thats why the reactions here surprise me. Fair enough that 
I do point out some use cases that are not in the INFO cases draft, but 
it was the whole INFO discussion that got me thinking that we have a 
need for a media-plane equivalent of INFO-events. TOTE is a nearly 
direct translation of the mechanism in Hadriels draft into the media 
plane. Purpose = info package, and the MIME negotiation is already there 
in SIP via Accept.

-Jonathan R.

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 18:11:25 +0200

Hi
About the analysis:

"Mediactrl solves the problem of binding a connection to a dialog by
defining a SYNC message. TOTE solves this problem by using ICE, which
provides this correlation as part of its normal operations. Mediactrl
solves the problem of keepalives using its own keepalive message; TOTE
uses the ICE keepalive mechanism."

I think that there is a difference there. Media control is using one
dialog to the media server for opening the control channel. On this
control channel the media server will get many controls that relate to
different dialogs created separately (users connecting to the media
server). The association is between a specific control command and a
dialog and not between the control channel and a dialog.

Roni Even.