RE: RFC 4612 - historic status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Monday, 14 August, 2006 03:41 -0400 "Paul E. Jones"
<paulej@xxxxxxxxxxxxxx> wrote:

> Brian,
> 
> The problem with using "image" is that it would mean that a
> gateway would have to do one of:
> 1) Close the audio session and open an image session
> 2) Open a second "image" session during mid-call
> 3) Open both an audio session and image session at the outset
> 
> For a lot of reasons, none of those options are preferred.  In
> the latter case, gateways just waste memory and CPU resources
> servicing sockets that are never used.  In the first two
> cases, there is a lot of extra signaling on the wire.  (For
> SIP networks, and especially IMS-based SIP networks, this is
> horrible due to the widespread use of UDP, slow timer
>...

Paul,

I think there may be a fundamental misunderstanding, or at least
difference in understanding, about top-level media types implied
in the above.  From a process standpoint, if you are just
finding out about it now, something has, IMO, failed (see my
other note).  But, putting that aside...

The "text/" top-level type, and only the "text/" top-level type
has the property that one can reasonably expect to be able to
display the contents to the user without understanding the
subtype.  Whether that is realistic or not, and how narrowly
that requirement should (or must) be interpreted to make
something "text/" has been widely debated in the past.

But, for all other media types, one cannot interpret them
without both the top-level type and the subtype.  As far as
transmission issues are concerned, the type-subtype distinction
is largely irrelevant: there is not, meaningfully, an "audio
session" or an "image session" as far as the media type is
concerned.   Where they do become somewhat relevant is at the
receiving end: if I don't have any way to render any image, then
an image type is, at best, going to need to be stored for later
retrieval even if it were to be fully understood.  Similarly for
audio: if the recipient does not have the capability to
reproduce or otherwise render sounds, then one can only store
the transmission contents for future processing or forward it
elsewhere (or reject the transmission on that basis).

A gateway that isn't structured around that model -- a model
that, at its most general, implies that the transmission forms
of media types are more or less just bits except to the network
end-points -- isn't necessarily wrong, but it will have far more
problems interworking smoothly and with minimal information loss
than the names of media types or the status attached to them.

regards,
   john


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]