Subject: RE: [SIP] Static Images

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 29 Jun 2000 03:06:52 -0700

However Dave, although Display-Info could be done using multiple headers
(anything is possible), I  don't believe this would be helpful. The parsing
is much more difficult and order is now important for multiple headers.
Adding purpose-specific parameters is IMO option a lot simpler and more
localized than adding new headers.

Come on, would you prefer

Display-Info: http:blah
Display-Purpose: picture
Display-Info: http:blah2
Display-Purpose: picture
Display-Info: http:blah3
Display-Purpose: myagent
Display-Other: whatever
Display-Info: inline:25487852
Display-Purpose: aboutme

or 

Display-Info: http:blah;purpose=picture
Display-Info: http:blah2;purpose=picture
Display-Info: http:blah;purpose=myagent;other=whatever
Display-Info: inline:25487852;purpose=aboutme
[or just comma separate them]

This is a very flexible & powerful feature and like anything that is very
flexible you want to make sure that flexibility does not turn into
widespread chaos - where there are a zillion SIP headers defined. Using only
only header 
a) abstracts/prevents the Display-Info flexibility from cluttering the core
SIP functionality and parsing.
b) localizes future extensions (the scope of any future parameter is limited
to that purpose type and not to ALL SIP processing!!)
c) removes the need correlate all the Display-* headers. Each header is
self-contained and order is unimportant. All Display info can be found in
one place - your Walmart of Display content.

Henning, so when are we going to see the new SIP draft with your syntax
proposal? <grin>

Cheers,

Robert.

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: Thursday, June 29, 2000 8:25 AM
To: Henning Schulzrinne; Adam B. Roach
Cc: Jonathan Rosenberg; Fairlie-Cuninghame Robert;
[email-masked]
Subject: Re: [SIP] Static Images

Henning's reductio ad absurdum really drove this home for me. If we want to
do something that needs a header, just invent a header.

We could go even further than Henning suggests and just cast SIP as a single
Lamba function in Common Lisp. Or better still, use my favorite
one-instruction programming language:

DWIM(arg1,arg2...)

where DWIM = "Do what I mean".

Dave.

> > I propose, then, that the purpose for *both* of your URIs
> > is the same: caller identification. I beleive the distinction you're
> > trying to make would be better illustrated by, for example, the
> > difference between a spoken name to identify the caller and
> > a custom alerting tone provided (or, more appropriately, suggested)
> > by the caller. The callee's device may then choose to present this
> > content appropriately.
> >
> > Display-Info: http://www.example.com/picture;purpose=callerid,
> >   http://www.example.com/hello.au;purpose=callerid,
> >   http://www.example.com/chimes.au;purpose=alerting
> >
>
> Given that we don't have to pay taxes for headers, and given that the
> number of purposes suggested so far is small, why all these parameters?
>
> Using, for example,
>
> To-Info:
> From-Info:
> Alert:
>
> is much shorter and it's much easier to tell what's going on. If we go
> the parameter route, I'd suggest being more consistent and rewriting SIP
> as
>
> Protocol-Info: some-url;purpose=to-address
> Protocol-Info: some-other-url;purpose=from-address
> Protocol-Info: 1234 INVITE;purpose=sequence-number
> Protocol-Info: INVITE;purpose=method
>
> :-)
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>
>

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

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

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 29 Jun 2000 08:06:42 -0400

Robert, perhaps you missed my point amidst the humor element. I was
advocating that the information actually be semantically tagged by the name
of the header so we don't have so much overloading and an extra identifier
space to manage. The tag method introduces a whole new identifier space with
its own semantics for the UA to understand, when the header would work just
fine. As Henning and others have ponted out, the rendering method (picture,
audio, video, smell, etc.) should be deduced by the UA from the content of
the URL when it's accessed rather than via URI names or purpose tags.

So, in my view, if you wanted a something to be presented to the user during
alerting, we'd have headers like:
Alerting-Info: http://doggie-heaven.aol.com/~mydogskip/mug.jpg
Alerting-Info: ftp://doggie-heaven.aol.com/~mydogskip/woof-woof.mp3
Alerting-Info: rtsp://doggie-heaven.aol.com/~mydogskip/phew-phew.sml
From-Info: http://doggie-heaven.aol.com/~mydogskip/skip.vcf

Depending on what the UA was capable of and the UA owner's preferences,
during alerting it could do one or more of:
a) display the picture of Skip
b) play Skip barking as the alerting sound
c) emit chemicals to simulate a very muddy unwashed skip walking into the
room.

and make available via some UI function Skip's vCard information to allow it
to be added to an address book, or whatever.

This making more sense?

Dave.

----- Original Message -----
From: "Fairlie-Cuninghame, Robert" <[email-masked]>
To: "'David R. Oran'" <[email-masked]>; "Henning Schulzrinne"
<[email-masked]>; "Adam B. Roach" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "Fairlie-Cuninghame,
Robert" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 29, 2000 6:06 AM
Subject: RE: [SIP] Static Images

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 29 Jun 2000 07:43:16 -0500 (CDT)

>to be added to an address book, or whatever.

I think the point that Jonathan is trying to make (and one
with which I agree) is that, for example, if you define a future
extension for some other semantics than "alerting" or "from," new
*headers* are suboptimal.

Henning's argument holds *only* if the header itself has
no associated semantics. In this case, it isn't true.
"Display-Info" conveys the concept that "this is additional 
content to be rendered for the user." The purpose 
parameters are merely giving hints as to how this 
information would most effectively be conveyed.

I'll demonstrate this point.

Sprog-Info: http://www.xyz.com/image.jpg

If your client didn't understand this new header type
of "Sprog-Info," it would be ignored. 

Display-Info: http://www.xyz.com/image.jpg;purpose=sprog

On the other hand, a client which understood the general
"Display-Info" header, but had no idea what this new "sprog" 
thing was would have a much better recovery. It could either 
present the image (possibly in a box labeled "sprog"), or at 
least let the user know: "I have an image here labeled 'sprog.' 
Do you want to see it?")

I see the second set of behavior as far preferable.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 29 Jun 2000 09:33:31 -0700

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.

Alerting-Info:  special ring or display
From-Info:      CallerID photos, .vcfs, spoken names, etc.
Error-Info:     Dave's pointer to error messages
Context-Info:   stuff relevant to the call (presentation, web page, photo, 
etc.)
etc...

thanks,
-rohan