[SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt

[Henning Schulzrinne]

> Of course it does. You are not displaying them to a user for the purpose
> of messaging and communications. If you are including content that has
> semantic meaning to some upper layer system, its not a MESSAGE. Its
> something else. MESSAGE does not just mean "deliver this to higher layer
> protocol stack". It means a very specific thing - render this content to
> the user, where this rendering is some kind of communication which might
> be responded to.

While I'm no fan of overloading names, I don't think it's quite as clear
cut as we'd like. Some considerations:

- It's bad if the same type of device (or the same name) gets two types
of messages with very different meaning. This doesn't seem likely in
this case.

- We already have different content for INVITE, distinguished by
Content-Disposition. It's a bit a matter of taste whether to use a
different Content-Disposition or a different message.  Thus, you
definitely need a different Content-Disposition, other than render.

- Having the same message makes sense if filtering, for example, would
likely be the same for both.

One could argue that a message being displayed to a user is just
electrons on phosphor. A message to a lightbulb is just a one-bit
phosphor. (After all, sending a MESSAGE to the Times Square news ticker
is nothing but turning on *lots* of lightbulbs... It's also likely to be
one-way.)

In this case, it's a matter of abstraction whether MESSAGE is taken as
only stuff that's text displayed to human users or more general.
Reasonable people can disagree, I believe. Do we need to apply a Turing
test to the recipient?

In summary, I think either a new message type or MESSAGE can be made to
work as long as the type of content is labeled clearly, not just in
terms of syntax but also semantics. If lots of people think it's
different enough and can describe the difference in some generic term
("MESSAGE is for messages for human consumption and is not expected to
have other consequences; generally two way", "CONTROL is for messages
for machine consumption that may trigger things, generally one-way"),
it's easier to just use another method name and be done with the
discussion.

> 
> I don't dispute that they might possibly in some cases move around, but
> it doesn't seem like the typical case. Choosing a protocol just for
> support of an unlikely case doesn't seem like the right thing to do.

I still don't understand the harm to SIP even if mobility is rare right
now (with suitable authentication, devices in cars may be quite usefully
be accessed remotely, e.g., for maintenance and diagnostic purposes).
Web clients are very hard to automate and script, so I don't see this as
a viable alternative in all cases.