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
_______________________________________________
Sip mailing list http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
