Subject: Re: [SIP] Static Images

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 01 Jul 2000 00:13:21 -0400

Sean Olson wrote:
> 
> > Adam,
> >
> > The "sprog" behavior reminds me of push advertising content.  I am
> > incredibly alarmed at the idea of displaying "sprog", or playing "sprog",
> > or continually prompting me if I want to see "sprog".  It's bad enough when
> > I surf with cookie protection turned on.  IMO, This non-semantically
> > defined rendering is more appropriate for Instant Messaging.
> >
> > Now if you really want your UA to always display whatever content your peer
> > barfs down to you, then I suggest we use headers, but create a convention
> > that all the header names end with -Info.  Then, when you get the headers:
> >
> > Sprog-Info: http://www.spam.com/annoying-animated.gif
> > Sprog-Info: http://www.spam.com/annoying.wav
> >
> > Your UA can match against unknown *-Info headers and a) happily render
> > them, b) prompt for them, or c) ignore them.
> 
> It can quite easily do the same when matching unknown "purpose=" parameters
> on a Display-Info: header. This is just a syntactical difference, not a
> semantic one. 

I agree. 

The only semantic difference between a header vs. a purpose parameter
is, as I and Adam pointed out, handling of unknown purposes. With a
header, they are discarded. With a parameter, the policy of the UA could
discard them or render them at its discretion. Since syntactic arguments
are fundamentally futile, I think it is useful to make a decision based
on the semantic differences. I prefer the more generally useful approach
of using the parameter.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Pathangi N Janardhanan" <[email-masked]>
Date: Sat, 1 Jul 2000 12:29:04 +0530

Hi,

  I have a few questions on implementation, and would appreciate some
clarifications.

a) The proxy/re-direct server needs to talk to a location server to
resolve the addresse
    information. Is there any standard work for this interaction
protocol, or in the absence
   of this, how would some one be able to write a SIP server to query
the location server?

b) Are there any requirements for scripts that the server must
support, say CLP, XML
    etc? i.e. is there a minimum set that any server must understand?
Is there any way for
    a client to know of this capability?

Thanks
Jana

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 01 Jul 2000 09:29:02 -0400

> on the semantic differences. I prefer the more generally useful approach
I agree, but would tend to view semantic equivalence as somewhat more
limited. For example, I don't think that error indication, ringing
indication and additional information about caller/callee can just all
be rendered if I don't recognize the purpose tag. As an example, if a
client doesn't know about distinctive ringing, just rendering the
header-indicated sound and local ringing at the same time is probably
less than ideal. In the end, I don't think header vs. parameters doesn't
matter all that much, so maybe it is more useful to gather applications
for this:

- ringing
- caller/callee web page
- caller/callee iconic/avatar representation (e.g., a small JPEG or GIF)
- possibly error indication

Anything else?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Igor Slepchin <[email-masked]>
Date: Sat, 01 Jul 2000 17:29:08 -0400

>    of this, how would some one be able to write a SIP server to query

This is left undefined on purpose, namely, to standard internet
principle of not defining anything that is not necessary for
interoperability. Take a look at sec. 1.4.5 of RFC2543bis for the
description of a few possible user location mechanisms.
 
>     etc? i.e. is there a minimum set that any server must understand?

No. It all depends on what services you want to provide to your
customers.

> Is there any way for a client to know of this capability?

Why would it want to know? Script execution is transparent to user
agents.

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2000 00:11:41 -0400

Igor Slepchin wrote:

> Why would it want to know? Script execution is transparent to user

If a user wants to upload a CPL to a server in a REGISTER, it can simply
try and if it fails with a 415 Unsupported Media, listing the type for
CPL, you know its not supported.

If you want to discover a proxy server that supports CPL, for example,
you can use the Service Location Protocol (SLP). We have recently
registered templates for discovering SIP servers based on capabilities.

Check out:
http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/sip.1.0.en
http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/sipproxy.1.0.en
http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/sipregistrar.1.0.en

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2000 00:18:34 -0400

Henning Schulzrinne wrote:
> be rendered if I don't recognize the purpose tag.

This is the big issue. My proposal is that this header be ONLY for
things which can be reasonably rendered without knowing the semantic
content. I think this includes things like jpeg/vcards for caller ID,
for example, but not distinctive ringing, as you point out.

 As an example, if a
> - possibly error indication

caller addrres information - vcard
FYI web content (BYE can contain a URL which points to a web page
discussed during the call)

-Jonathan R.

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 05 Jul 2000 00:19:10 -0400

> CPL, you know its not supported.

Well, I'd rather call it a provisioning client then, not a SIP client.
I'd assume that a provisioning client knows the capabilities of the
proxy it's trying to provision. After all, if it tries to provision a
random proxy, the authentication with that proxy will most likely fail.

Finding a proxy with a given set of capabilities is a totally different
story. Note that SLP doesn't really work beyond LAN.

Thank you,
Igor Slepchin

---

From: Michael Thomas <[email-masked]>
Date: Wed, 5 Jul 2000 12:37:01 -0700 (PDT)

> for example, but not distinctive ringing, as you point out.

   I continue to feel that inlining content is just a
   really awful idea. The slippery slope you
   mention here is one reason, but the thing that
   really bugs me is the MTU issue for UDP. The
   thought of SIP regularly transmitting fragments
   so that you can see somebody's mug seems like a
   fundamentally broken idea. Also: I'm not sure
   how you'd break larger content across messages.
   Another thing that pretty much sucks is that if
   the content is shipped through proxies, you be
   putting an awful lot of extra transaction load
   on the proxies who would have to do useless 
   fragmentation kruft (from their vantage).

   I know that Henning is likely to chime in here
   extolling the virtues of TCP, but UDP is a
   valid transport for SIP, and in some ways
   limited MTU is a sanity check for those who
   would like to use SIP as a kitchen sink
   transport.

   If we have to do this at all, what's wrong with
   multipart mime? Isn't there a way with mime to 
   ship fragments of content already? Better yet:
   URL's are your friends.

	     Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 05 Jul 2000 15:47:38 -0400

>    I continue to feel that inlining content is just a

Before this gets another discussion started: Inlining is *not*
suggested. Just URLs. Something like

Call-Info: <http://www.example.com/myhomepage>

[If you *really* want to inline, the data: URL can do that, too, but I
didn't say that.]

That's what in the current edition of RFC2543bis.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs