Re: [Sip] MESSAGE for rendering Fri, 14 December 2007 23:27 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1J3Jwd-00051C-1K; Fri, 14 Dec 2007 18:27:51 -0500
Received: from sip by with local (Exim 4.43) id 1J3Jwb-000516-98 for; Fri, 14 Dec 2007 18:27:49 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1J3Jwa-00050y-Vm for; Fri, 14 Dec 2007 18:27:48 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1J3Jwa-00045K-IO for; Fri, 14 Dec 2007 18:27:48 -0500
Received: from ([]) by with comcast id QlY91Y00F0mlR8U0A09X00; Fri, 14 Dec 2007 23:27:53 +0000
Received: from ([]) by with comcast id QnTr1Y0070umElk8X00000; Fri, 14 Dec 2007 23:27:53 +0000
X-Authority-Analysis: v=1.0 c=1 a=9BcAZO5vLVsiOuOlEw4A:9 a=dFAO3tKwpzy4TCXN6YAA:7 a=2ye5IWAOkg2fW1Te4Vr-3eAGJewA:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10
Received: from ( []) by (8.12.8/8.12.8) with ESMTP id lBENRjPC023458 for <>; Fri, 14 Dec 2007 18:27:45 -0500
Received: (from worley@localhost) by (8.12.8/8.12.8/Submit) id lBENRjRq023454; Fri, 14 Dec 2007 18:27:45 -0500
Date: Fri, 14 Dec 2007 18:27:45 -0500
Message-Id: <>
In-reply-to: <> (
Subject: Re: [Sip] MESSAGE for rendering
References: <> <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

   From: Paul Kyzivat <>

   I am entirely with you if the *intent* of sending the vcard is to render 
   it to the user in some human readable way. Its hardly any different from 
   sending HTML.

   Its much more questionable if the intent is that the vcard be filed in 
   the recipients address book without being rendered.

IMHO, filing information is as good as actually rendering it.  The
real question is layering -- "render" means "deliver to the layer
above the SIP UA".  Anything that partakes of media is "rendered" and
is acceptable for MESSAGE, anything that partakes of signaling is not
"rendered" and is acceptable for INFO.

One criterion is "Would it make sense to let the user arbitrarily
re-route where this information goes?"  With a vcard, it makes sense.
With the information INFO was intended to carry, it does not:

   RFC 2976 1.1 Example Uses

      The following are a few of the potential uses of the INFO message:

      - Carrying mid-call PSTN signaling messages between PSTN

      - Carrying DTMF digits generated during a SIP session.

      - Carrying wireless signal strength information in support of
        wireless mobility applications.

      - Carrying account balance information.
	[in a pay-as-you-go network -- DRW]


Sip mailing list
This list is for NEW development of the core SIP Protocol
Use for questions on current sip
Use for new developments on the application of sip