Subject: RE: [SIP] Static Images

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 23 Jun 2000 18:09:10 -0700

Perhaps an accompanying *-Disposition or *-Type or *-Function header to
describe the purpose of *-Info would be helpful. This stops a UA trying to
display something that was not supposed to be. Actually, IMO, this goal
would perhaps be better served by incorporating the
function/type/disposition information into the actual *-Info field. This
would make the provisioning of multiple *-Info headers much simpler. 

Display-Info (simple but can be misleading), Optional-Info,
Optional-Content, Fluff-Info? :)

Robert.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Friday, June 23, 2000 9:42 PM
To: Jonathan Rosenberg
Cc: Fairlie-Cuninghame, Robert; Adam B. Roach; Henning Schulzrinne;
Billy Biggs; Colin Perkins; [email-masked]
Subject: Re: [SIP] Static Images

This sounds find (I'll incorporate it), but I do wonder if one wouldn't
want to be more specific in the purpose of the header, rather than just
"URI". For the 'visual caller id', something like '*-Info' (with a
suitable value of *, TBD) seems more evocative. I don't want to follow
the INFO tradition of dumping everything into one header. This may be
relevant, for example, as to whether the UA uses this information to
update some kind of address book.

Jonathan Rosenberg wrote:
> 
> So, in the interests of coming to consensus, let me propose that:
> 
> 1. inline content MAY be included, possibly using multipart. This would
> obviously include MIME types like application/URI-list which are
> themselves indirect references
> 2. we define a new header, called URI or something, which contains
> indirect references to content that is to be displayed. The header is
> totally optional to process at UAS. It cannot be used for content that
> is critical for processing the request properly.
> 
> We also RECOMMEND that proxies use the URI header when inserting
> content. A UA inserting content can use either, but indirect references
> are RECOMMENDED for content over 500 bytes (or some other number). In
> this way, if a UAC sends content inline using multipart, and the UAS
> doesn't support it, the 415 response will indicate that multipart isn't
> supported. The UAC can then resubmit the request using the URI header.
> 
> This keeps things open and flexible, but makes concrete recommendations
> to guide implementors (i.e, supporting the URI header would be your
> first choice).
> 
> -Jonathan R.
> 
> Henning Schulzrinne wrote:
> >
> > The problem with having proxies add body parts is (a) complexity, (b)
> > that now all clients have to understand multipart, even if they have no
> > interest in the information (I would guess that most current SIP clients
> > don't understand multipart) and (c) that it doesn't work with signed
> > requests. Headers containing a reference (http:, say) avoid these
> > problems. The only drawback is that such references require http support
> > in clients (which may be an issue for a very light-weight clients, but
> > most of these are probably graphically challenged anyway) and requires
> > that the information is available on a publically accessible web page. I
> > suspect that most corporate users would have difficult uploading their
> > likeness or other images to a web page, and not everyone wants to have
> > their likeness framed by an advertisement from geocity or kin. These
> > are, more or less, the arguments that were made the last time this topic
> > came around, I believe.
> 
> --
> 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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jun 2000 00:17:51 -0400

> would make the provisioning of multiple *-Info headers much simpler.

Agree; sounds like a parameter:

Display-Info: http://www.example.com/picture;purpose=picture,
  http://www.example.com/hello.au;purpose=speakname

We would need to define some basic purpose values, and then define a
procedure for specifying new ones with IANA.

-Jonathan R.

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 26 Jun 2000 07:58:07 -0500 (CDT)

>procedure for specifying new ones with IANA.

I'm with Henning on this one: your values seem to imply a certain
type of *rendering*, not a certain type of information -- and,
in HTTP at least, it's the client's responsiblity to render the
content type fetched in a appropriate form.

Display-Info: http://www.example.com/call-id/adam.roach

For example, if you fetch this URI with an Accept of
"audio/*", and no video parameters, the HTTP server
may return an audio clip. If you send both of
"audio/*, image/*", it may return a GIF instead.
This has to do with trusting the way HTTP currently
handles browser capabilities.

I know this isn't widely used right now, even though
servers (and browsers) support it; I'm sure
this type of use of HTTP will expand as terminals
evolve away from 17" screens with 101-key keyboards.

-- 
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jun 2000 13:39:37 -0400

> content type fetched in a appropriate form.

No, they don't imply any kind of mandated behavior. I was trying to
address a concern raised previously on the list, which was that just the
MIME type wasn't enough. Is this image a thumbnail of the caller? Is it
a picture of a phone for a "graphical custom ringing" or something? The
idea with this purpose thing was just a hint to indicate the purpose of
the content, so that the device could do with it something reasonable,
as it saw fit. 

-Jonathan R.

---

From: Richard Shockey <[email-masked]>
Date: Mon, 26 Jun 2000 15:36:00 -0500

>the content, so that the device could do with it something reasonable,

Gentlemen ... I'd like to offer a "RATHOLE ALERT" here.

The problem of defining content-types and the priority of those 
content-types in processing has been thoroughly debated in the VPIM WG with 
no conclusion.

Please note  { draft-burger-vpim-cc-00.txt } for some background discussion 
of what you are getting into.

The context of each application is different but the problem statement is 
quite similar.

Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 27 Jun 2000 08:56:38 -0500 (CDT)

>the content, so that the device could do with it something reasonable,

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Jun 2000 10:02:21 -0400

>   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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Jun 2000 21:41:36 -0400

> number of purposes suggested so far is small, why all these parameters?

The difference is that with a single header, if you don't understand the
parameter that gives a "hint" on what its for, you still know to display
it. If you use a separate header for each "hint", then as we come up
with new purposes, they won't be handled at all by older UAs.

In general, parameters make sense when they further qualify the
semantics implied by the header. I think this is the case here. The
header says "render this". The parameter provides an application layer
hint, which may be ignored, saying for what purpose this should be
rendered.

-Jonathan R.

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 28 Jun 2000 20:25:12 -0400

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.