Subject: RE: [SIP] Static Images

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 26 Jun 2000 00:02:59 -0700

Perhaps this Display-Info field could also be used to describe inline
content. This means that all information regarding optional content is in
the same place.

Display-Info:
http://www.example.com/picture;purpose=picture,inline:2;purpose=aboutme

where inline:2 means that the content is contained in the second multipart
body. [Although this would place a requirement on proxies adding multipart
bodies to place them at the end.]

Do you think that a mime type parameter is required (especially for URL's)?
eg 
Display-Info: http://www.example.com/picture;purpose=picture;type=image/tiff

Robert.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, June 26, 2000 12:18 PM
To: Fairlie-Cuninghame, Robert
Cc: 'Henning Schulzrinne'; [email-masked]
Subject: Re: [SIP] Static Images

"Fairlie-Cuninghame, Robert" wrote:
> 
> 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.

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.

-- 
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: Lawrence Conroy <[email-masked]>
Date: Mon, 26 Jun 2000 09:41:36 +0100

>Display-Info: http://www.example.com/picture;purpose=picture;type=image/tiff
Problem is, there is an ASSUMPTION here that the body parts are never 
re-ordered.
This would require a prohibition or re-ordering, as implied above.

If you use the body part content-ID field instead of just a plain 
part index, then
re-ordering is no longer a problem, and we don't have to add such a 
prohibition.
Thus, inline:2@3456 indicates the subpart with a content-id:2@3456.
MIME Content-ID is defined Appendix A of RFC 2045, and that in turn 
took it from
RFC822. We stand on the shoulders of giants.
-- 
All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd pay me for them"    |
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Jun 2000 08:41:45 -0400

> Display-Info: http://www.example.com/picture;purpose=picture;type=image/tiff

I know this is tempting, but can we please make this implementable in
less than a GHz Pentium workstation and describable in less than 30
pages? 

Adding MIME types to a URL is a really bad idea. URLs may well map to
several different MIME types, depending on content negotiation. (This is
implemented in Apache, for example.)

Since it doesn't matter, semantically, whether you speak something or
display it, I would also be disinclined about being too specific about
the rendering method used. We don't do this for the web, either.

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