Subject: RE: [Simple] I-D ACTION:draft-lonnfors-simple-partial-notify-00.t xt

From: "Mark Watson" <[email-masked]>
Date: Tue, 4 Mar 2003 09:32:18 -0000

All,

I am not convinced by the discussion on SIGCOMP which has been introduced
into this draft (Section 1.1).

Firstly, is this even the correct place to describe these issues ?? If we
really expect to see large binary content in SIP messages, then we should
document the impacts for SIGCOMP somewhere more general - not buried in a
presence partial notifications discussion. If we do not expect such content,
we should document that fact somewhere more general too. We need to make a
decision one way or the other because it has important implications for the
design of SIGCOMP compressors.

Secondly, two of the solutions referred to involve the SIGCOMP layer having
knowledge of the content type, which is a major architectural change.
Presently, the SIGCOMP layer does not parse SIP, MIME etc.

Thirdly, the last solution mentioned involves leaving 'binary' content
uncompressed, but this does not necessarily mean that this content will not
mess up the dynamic dictionary. The compression scheme would need to detect
'uncompressible' parts of the message and leave these out of the dictionary.

So, if we expect binary content in SIP, we should document the impacts in
SIGCOMP somewhere in the sip/sipping WGs. We should decide whether we expect
SIGCOMP to cope with such binary content in an efficient way (i.e. if we
think the same content will be sent multiple times) or whether we are happy
for SIGCOMP to leave such content uncompressed (i.e. if we think the same
content will generally only be sent once).

Finally, I think we concluded in the last discussion on this that it was not
appropriate to include in-line binary content in the presence document
itself due to encoding issues - there is still some reference to this in the
draft. Large binary content would need to referenced from the presence
document, and we left it open whether this reference could be to other MIME
parts within the same SIP message.

Regards,

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 24 February 2003 11:45
> Cc: [email-masked]
> Subject: [Simple] I-D 
> ACTION:draft-lonnfors-simple-partial-notify-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Partial Notification of Presence Information
> 	Author(s)	: J. Costa-Requena, E. Leppanen et al.
> 	Filename	: draft-lonnfors-simple-partial-notify-00.txt
> 	Pages		: 24
> 	Date		: 2003-2-21
> 	
> A Presence service implemented using SIMPLE has some constraints for 
> delivering presence information to devices with low data processing 
> capabilities, small display, and limited battery power. Other 
> limitations can be caused by the interface between the terminal and 
> the network, i.e. over radio links with high latency and low 
> bandwidth. This memo presents a solution that aids in reducing the 
> impact of those constrains and increasing efficiency, by introducing 
> a new MIME-type æpartial notificationsÆ and a Require header 
> extension æpartial-notificationÆ.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part
> ial-notify-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-lonnfors-simple-partial-notify-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-lonnfors-simple-partial-notify-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 5 Mar 2003 10:33:17 -0000

Mikko, All,

The correct place to document such recommendations about SIGCOMP would be in
some ROCH documentation, perhaps the SIGCOMP User Guide ? I notice that
RFC3322 (Signalling Compression Requirements & Assumptions) already assumes
that the signalling messages are ASCII encoded, so if this is not the case I
think it's fairly urgent to get some discussion going.

Before we go to ROCH, though, we need to make some decision on what kind of
content we see being commonly included in SIP messages - i.e. what does
SIGCOMP have to deal with in addition to SIP Headers and SDP ??

To my mind this is a discussion for SIPPING - does anyone object to moving
this discussion there ? (Let's avoid creating a cross-posted thread if
possible - they're always a nightmare).

...Mark

> From: [email-masked] [mailto:[email-masked]]
> Sent: 04 March 2003 10:03
> To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
> Subject: RE: [Simple] I-D
> Hi mark,
> Inline inside <ML>:
> I am not convinced by the discussion on SIGCOMP which has 
> been introduced into this draft (Section 1.1). 
> Firstly, is this even the correct place to describe these issues ??
> 
> <ML> 
> Yes, you are right. To move discussion forward we needed to 
> place text somewhere and in this case only place we could 
> place it was the partial notification draft.
> </ML>
> 
>  If we really expect to see large binary content in SIP 
> messages, then we should document the impacts for SIGCOMP 
> somewhere more general - not buried in a presence partial 
> notifications discussion.
> 
> <ML>
> Yes
> </ML>
> 
> If we do not expect such content, we should document that 
> fact somewhere more general too. We need to make a decision 
> one way or the other because it has important implications 
> for the design of SIGCOMP compressors.
> 
> <ML>
> This is probably true.
> </ML>
> 
> Secondly, two of the solutions referred to involve the 
> SIGCOMP layer having knowledge of the content type, which is 
> a major architectural change. Presently, the SIGCOMP layer 
> does not parse SIP, MIME etc.
> 
> <ML>
> We have been talking about this issue with SIGCOMP author Z. 
> Liu (as at least I not an expert in this are) and these were 
> mentioned as possible solutions for this problem. I am also 
> not convinced that these two solutions are the best ones and 
> if other people feel same I am quite happy to drop them.
> </ML> 
> 
> Thirdly, the last solution mentioned involves leaving 
> 'binary' content uncompressed, but this does not necessarily 
> mean that this content will not mess up the dynamic 
> dictionary. The compression scheme would need to detect 
> <ML>
> As far as I know this should be quite easy thing to 
> accomplish for a SIGCOMP implementation. Of course it should 
> be specified (recommended) somewhere what is appropriate 
> threshold value for data which should be considered 'uncompressible'.
> </ML>
> 
> So, if we expect binary content in SIP, we should document 
> the impacts in SIGCOMP somewhere in the sip/sipping WGs. We 
> should decide whether we expect SIGCOMP to cope with such 
> binary content in an efficient way (i.e. if we think the same 
> content will be sent multiple times) or whether we are happy 
> for SIGCOMP to leave such content uncompressed (i.e. if we 
> think the same content will generally only be sent once).
> 
> Finally, I think we concluded in the last discussion on this 
> that it was not appropriate to include in-line binary content 
> in the presence document itself due to encoding issues - 
> there is still some reference to this in the draft. Large 
> binary content would need to referenced from the presence 
> document, and we left it open whether this reference could be 
> to other MIME parts within the same SIP message.
> 
> <ML>
> Yes, this is our mistake. I also agree that large binary data 
> should not be in-line with other presence data. This will be 
> fixed in next version
> </ML> 
> 
> Thanks for comments
> - Mikko
> 
> Regards, 
> Mark