Subject: RE: [Simple] New I-Ds on partial notification

From: [email-masked]
Date: Tue, 4 Feb 2003 02:06:22 +0200

Hi,

Comments inline.

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> >>Such a differentiated charging model for content opens the door for
> >>fraud. If sending content through presence is free, but costs money 
> >>other ways, won't users just always send content through presence?
> > 
> > 
> > I didn't want to imply that it would be free. Points was 
> that operators
> > would like to implement service based charging for some 
> services. For
> > example without signaling context being free users would 
> have to pay for
> > unanswered calls.    
> 
> That doesnt change the point here. If transfer of content within 
> presence is covered as part of my fee for the service, but 
> fetching of 
> content outside of it costs money, then users will end up generally 
> sending content through the presence service because its cheaper.

But the scope of this problem extends way past any protocol issues. It is down to the service offering to balance the charging model appropriately, so that the above scenario doesn't occur. The opposite could also easily happen; if CI'd content was too expensive to fetch, people wouldn't go and fetch it at all.
 
> Anyway, if you do wish to do such a thing, and you are using the PDP 
> conext to flag what is byte-metered vs. what is not, the real 
> problem is 
> that you can only bind a PDP context to a single protocol. Many 
> protocols and operations may be involved in providing a 
> service. That is 
> the root cause problem. Designing application protocols to fit the 
> packet metering methodology is not.

But I don't know if Mikko meant exactly that. I guess the problem wrt presence is that you can't easily e.g.,  differentiate the presence-originated HTTP traffic for CI from other similar traffic and this reduces the number of available options in creating the charging models.

However, I'm more concerned about the security implications. Firstly, "transferring" the watcher-PS security association to CI doesn't seem trivial. This of course depends on the security model, but for example, any model where presence authorization is based on asserted identities has some difficulty in authorizing CI. 

Secondly, I'm worried about performance in cases where the watcher needs to do CI fetching securely. For example, if a client sits behind a persistent TCP/TLS connection to a proxy and receives all notifications via that connection, doing a lot of HTTPS-sessions for CI on the side seems like a pretty big penalty.

> >>>CI requires some storage where content should be places until its
> >>>fetched or it expires. This box then needs to maintained 
> >>
> >>and connected
> >>
> >>>to existing network elements like PS. This may be
> >>
> >>unnecessary overhead
> >>
> >>>for some systems.
> >>
> >>No doubt this is extra infrastructure to maintain. However,
> >>such things 
> >>will frequently exist anyway (i.e., MMSC provides a similar 
> function).
> > 
> > 
> > MMSC (Multimedia Messaging Service Centre) is network 
> element used in
> > messaging service. In some systems such elements exist but 
> to require
> > such element being present to implement presence or to 
> couple messaging
> > service to presence may not make that much sense. 
> 
> If you are not using messaging, you can get something else 
> that provides 
> the function that is not an mmsc. Repositories for content 
> are not hard 
> to come by.

Rather than the availability of appropriate repositories, isn't the problem really that publishing that content is not standardized. It seems odd that publishing CI is not on our agenda, but publishing presence is. They seem to be parts of the same problem here, since we can't have one without the other.

[snip]

> >>I have problem with partial notifications. I dont mind
> >>developing a spec 
> >>for them either. However, I think their need is greatly 
> >>overestimated, 
> >>and it will buy you far less than you think for the complexity it 
> >>introduces.
> > 
> > 
> > This is fair. However, reading your mail I couldn't find 
> any of these
> > complexities. Could you be more specific what you think causes this
> > complexity. As the partial notification mechanism is 
> largely based on
> > same mechanism as winfo is PS and UAs should already (if 
> they support
> > winfo)  have means to handle partial notifications.
> 
> Yes, it is the same as winfo, more or less. The complexity 
> there is the 
> need for the UA to handle partial information, ask for full-state 
> updates, and for the server to deal with this as well. Its 
> not hard, but 
> it requires code and specifications to do. The point I have 
> been trying 
> to make is that I believe you need content indirection in 
> either case, 
> and so the benefits of the partial notifications are quite 
> small, IMHO, 
> not big enough to outweigh the work they introduce.

I agree that the issues seen with CI need to be solved anyway, because the mechanism will anyway be needed e.g. in messaging. It's then a different question that if the implied problems in security, charging and storage were solved, would we even have partial notification on the table?

Cheers,
Aki
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Peter Hedman (EMP)" <[email-masked]>
Date: Tue, 4 Feb 2003 08:59:54 +0100

Hi,

Agree that the issues with CI needs to be solved, but IMHO partial notifications will anyway be useful as the Presence info includes location info that may change often and the mechanism might even be one step towards accepting usage of S/MIME to protect Presence info considering the usage of SigComp in 3GPP. 

Also, the mechanism seem to be backward compatible i.e. the UA don't need to support it. Also, I assume the first NOTIFY per SUBSCRIBE will contain full state i.e. normally no need to explicitly request for full state update.

It is true that the mechanism need to be specified, but the new draft seems to be a reasonable approach.

BR,
Peter

> I agree that the issues seen with CI need to be solved 
> anyway, because the mechanism will anyway be needed e.g. in 
> messaging. It's then a different question that if the implied 
> problems in security, charging and storage were solved, would 
> we even have partial notification on the table?
> 
> Cheers,
> Aki

---

From: [email-masked]
Date: Tue, 4 Feb 2003 10:17:58 +0200

Hi,

inline
> 
> Hi,
> 
> Agree that the issues with CI needs to be solved, but IMHO 
> partial notifications will anyway be useful as the Presence 
> info includes location info that may change often and the 
> mechanism might even be one step towards accepting usage of 
> S/MIME to protect Presence info considering the usage of 
> SigComp in 3GPP. 
> 
> Also, the mechanism seem to be backward compatible i.e. the 
> UA don't need to support it.

Yes, this is true.

> Also, I assume the first NOTIFY 
> per SUBSCRIBE will contain full state i.e. normally no need 
> to explicitly request for full state update.

First NOTIFY will contain full state. I guess what Jonathan referred to
with full state update was that if UA for some reason misses one
notification (carrying partial info) UA must then fetch full presence
state to construct coherent presence state. This should not normally
happen but this needs to be specified in any case. Same applies also to
winfo.

BR
- Mikko

> It is true that the mechanism need to be specified, but the 
> new draft seems to be a reasonable approach.
> 
> BR,
> Peter
> 
> > > >

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 5 Feb 2003 15:48:09 -0000

I am really skeptical about the suggestion that large binary data content
will be included in-line in the presence document itself. How will this be
done ?

Unless I mis-understand, the presence document is an XML document encoding
in UTF-8 - i.e. it's a text document. Can you really include raw binary data
in-line ?? What content-transfer-encoding will you use ? How will a standard
XML parser react to this ? Does XML have a mechanisms for indicating that
arbitrary binary data follows and indicating the length of that data ?

If the binary data is e.g. base64 encoded, then you've immediately broken
your efficiency requirement. Even if the raw binary data can be included
in-line, the chances are that any SIP compression on the access link will
end up expanding this portion of the message. (That is unless the compressor
in use is specifically designed with the requirement to handle arbitrary
binary data efficiently. But since the compressor is chosen by the edge
proxy, how can you know this ?)

I would expect SIP compressors to be optimised to handle text-based messages
and, if only for this reason, I think we should generally try and stick with
text based signalling within the SIP message (and yes, we do have to do
something about S/MIME encryption here!). As I mentioned at the 3GPP/IETF
workshop that we have to pay continuing attention to the compressibility of
SIP messages.

There have been many threads on the general undesirability of using SIP to
transport large content files around. Further, on a 3GPP-specific note, this
approach would make it much more difficult to get any kind of reliable idea
of the bandwidth/QoS requirements for the signalling-specific radio
resource. Whilst you may wish to allow this resource to be used for content
as well, I do not think people should be mandated to do this.

Finally, one of your requirements is to cope with devices of various
form-factors/capabilities and the ability to render multi-media content is
one capability which varies greatly from device to device - I really do not
want to send a video clip even once to a device which can't render it.

I do not see what the big deal is with including a URI for any such content
in the Presence Document. This has so many advantages:
a) The content is only sent when it changes (even with your proposal, it is
sent at least every time a watcher subscribes)
b) The content is only sent to devices which can render it
c) The content need only be sent when the device actually needs to render it

Jonathan explained how security could easily be made no worse than for
in-line content.

On charging you solution is to require that this data is charged in the same
way as the rest of SIP signalling - but this solution does not imply that
the data is carried *in* SIP signalling. If this is what you want to do,
then just allow HTTP requests to a local HTTP-proxy (designated for this
purpose) to use the signalling resource.

Until we've bottomed out this in-line content question, I don't see how we
can conclude on whether partial notifications are valuable or not.

Regards,

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 28 January 2003 07:35
To: [email-masked]
Subject: [Simple] New I-Ds on partial notification

Hi, 
Here are links to two new drafts which deal with partial presence
notifications. 
Requirements are discussed here: 
http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-req
s-00.txt 
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 requirements for a solution that aids 
in reducing the impacts of those constrains and increasing 
efficiency. 
And the actual solution is described here: 
http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-00
.txt 
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. 
All comments are most welcome. 
Regards 
- Mikko

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 5 Feb 2003 17:21:16 -0000

One more reason why in-line content breaks SIP Compression: Most compression
schemes have a limit on how far they can 'reach back' into the message
stream to reference repeated strings. This distance may be further limited
by the UDVM memory. Depending on the compression scheme, large in-line
content may cause all useful state to be lost, so that the compression ratio
drops right down.
 
...Mark

-----Original Message-----
From: Watson, Mark [MOP:EP10:EXCH] 
Sent: 05 February 2003 15:48
To: [email-masked]'; [email-masked]
Subject: RE: [Simple] New I-Ds on partial notification

Regards, 

Mark 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 28 January 2003 07:35 
To: [email-masked] 
Subject: [Simple] New I-Ds on partial notification 

Hi, 
<http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-re
qs-00.txt>  
<http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-0
0.txt>

---

From: [email-masked]
Date: Wed, 5 Feb 2003 19:51:16 +0200

Is this really so? I would hope SIP compression doesn't break because of large (binary) content in the message payload. It would mean sending a jpeg mug shot in an INVITE will also break it, along with MESSAGE with any multimedia in it.

And I agree, base64 encoding may not be the best way. How about including the content using cids and a MIME multipart? Just a thought.

Cheers,
Aki

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 05 February, 2003 19:21
To: [email-masked]
Subject: RE: [Simple] New I-Ds on partial notification

One more reason why in-line content breaks SIP Compression: Most compression schemes have a limit on how far they can 'reach back' into the message stream to reference repeated strings. This distance may be further limited by the UDVM memory. Depending on the compression scheme, large in-line content may cause all useful state to be lost, so that the compression ratio drops right down.

...Mark
-----Original Message-----
From: Watson, Mark [MOP:EP10:EXCH] 
Sent: 05 February 2003 15:48
To: [email-masked]'; [email-masked]
Subject: RE: [Simple] New I-Ds on partial notification

I am really skeptical about the suggestion that large binary data content will be included in-line in the presence document itself. How will this be done ?
Unless I mis-understand, the presence document is an XML document encoding in UTF-8 - i.e. it's a text document. Can you really include raw binary data in-line ?? What content-transfer-encoding will you use ? How will a standard XML parser react to this ? Does XML have a mechanisms for indicating that arbitrary binary data follows and indicating the length of that data ?
If the binary data is e.g. base64 encoded, then you've immediately broken your efficiency requirement. Even if the raw binary data can be included in-line, the chances are that any SIP compression on the access link will end up expanding this portion of the message. (That is unless the compressor in use is specifically designed with the requirement to handle arbitrary binary data efficiently. But since the compressor is chosen by the edge proxy, how can you know this ?)
I would expect SIP compressors to be optimised to handle text-based messages and, if only for this reason, I think we should generally try and stick with text based signalling within the SIP message (and yes, we do have to do something about S/MIME encryption here!). As I mentioned at the 3GPP/IETF workshop that we have to pay continuing attention to the compressibility of SIP messages.
There have been many threads on the general undesirability of using SIP to transport large content files around. Further, on a 3GPP-specific note, this approach would make it much more difficult to get any kind of reliable idea of the bandwidth/QoS requirements for the signalling-specific radio resource. Whilst you may wish to allow this resource to be used for content as well, I do not think people should be mandated to do this.
Finally, one of your requirements is to cope with devices of various form-factors/capabilities and the ability to render multi-media content is one capability which varies greatly from device to device - I really do not want to send a video clip even once to a device which can't render it.
I do not see what the big deal is with including a URI for any such content in the Presence Document. This has so many advantages:
a) The content is only sent when it changes (even with your proposal, it is sent at least every time a watcher subscribes)
b) The content is only sent to devices which can render it 
c) The content need only be sent when the device actually needs to render it 
Jonathan explained how security could easily be made no worse than for in-line content. 
On charging you solution is to require that this data is charged in the same way as the rest of SIP signalling - but this solution does not imply that the data is carried *in* SIP signalling. If this is what you want to do, then just allow HTTP requests to a local HTTP-proxy (designated for this purpose) to use the signalling resource.
Until we've bottomed out this in-line content question, I don't see how we can conclude on whether partial notifications are valuable or not.
Regards, 
Mark 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: 28 January 2003 07:35 
To: [email-masked] 
Subject: [Simple] New I-Ds on partial notification 

Hi, 
Here are links to two new drafts which deal with partial presence notifications. 
http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-reqs-00.txt 
http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-00.txt

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 5 Feb 2003 18:20:19 -0000

Aki,

Well, it depends on the compression algorithm used. Certainly the simple
ones do little more that send a string of <offset,length> pairs to reference
strings which occured earlier in the data stream - of course with some way
of escaping to literal data. So, certainly, large in-band binary content
will reduce the effectiveness of these schemes.

You could mitigate this by ensuring that the static dictionary never goes
out of view, or, for example, only storing the first X octets of each
message, where X is chosen to usually cover the headers and SDP.

Other schemes build up a dictionary of codewords e.g. in LZW then the
codebook is built up by allocating a new codeword for the previous phase
plus the next character. Common phrases will end up appearing in more
codewords and in longer referenced strings. I think this would not be so
affected by raw binary data, since this wouldn't disrupt the codebook
already built.

However, I'm not so sure this is the best scheme for SIP signalling, since
it takes quite a while to build up the codebook. You want, for example, to
be referencing back to the entire Request URI when it appears again in the
To field a few octets later, and then do the same in subsequent
requests/responses - not sure LZW would get you this.

DEFLATE, if I remember correctly, does LZW & then Huffman encodes the
result.

In my personal opinion, binary content in SIP messages, including the Caller
Photo & Multimedia Messages is a bad thing per se and Content Indirection
should always be used. (As Jonathan mentioned, the existing MMS does not
send the content with the notification of the message - you have to fetch
it).

Having said that, referencing out from the Presence Document to something
which might be at a URL or might be in another MIME part of the Notification
might provide a way forward - of course I'd still say that these other MIME
parts should be Content-Indirected :-), but at least you have solved the
encoding problem and brought the compression problems into the same space as
Caller-photos etc.

...Mark

> From: [email-masked] [mailto:[email-masked]]
> Sent: 05 February 2003 17:51
> To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
> Is this really so? I would hope SIP compression doesn't break 
> because of large (binary) content in the message payload. It 
> would mean sending a jpeg mug shot in an INVITE will also 
> break it, along with MESSAGE with any multimedia in it.
> 
> And I agree, base64 encoding may not be the best way. How 
> about including the content using cids and a MIME multipart? 
> Just a thought.
> 
> Cheers,
> Aki
> 
> 
> One more reason why in-line content breaks SIP Compression: 
> Most compression schemes have a limit on how far they can 
> 'reach back' into the message stream to reference repeated 
> strings. This distance may be further limited by the UDVM 
> memory. Depending on the compression scheme, large in-line 
> content may cause all useful state to be lost, so that the 
> compression ratio drops right down.
> 
> ...Mark
> I am really skeptical about the suggestion that large binary 
> data content will be included in-line in the presence 
> document itself. How will this be done ?
> Unless I mis-understand, the presence document is an XML 
> document encoding in UTF-8 - i.e. it's a text document. Can 
> you really include raw binary data in-line ?? What 
> content-transfer-encoding will you use ? How will a standard 
> XML parser react to this ? Does XML have a mechanisms for 
> indicating that arbitrary binary data follows and indicating 
> the length of that data ?
> If the binary data is e.g. base64 encoded, then you've 
> immediately broken your efficiency requirement. Even if the 
> raw binary data can be included in-line, the chances are that 
> any SIP compression on the access link will end up expanding 
> this portion of the message. (That is unless the compressor 
> in use is specifically designed with the requirement to 
> handle arbitrary binary data efficiently. But since the 
> compressor is chosen by the edge proxy, how can you know this ?)
> I would expect SIP compressors to be optimised to handle 
> text-based messages and, if only for this reason, I think we 
> should generally try and stick with text based signalling 
> within the SIP message (and yes, we do have to do something 
> about S/MIME encryption here!). As I mentioned at the 
> 3GPP/IETF workshop that we have to pay continuing attention 
> to the compressibility of SIP messages.
> There have been many threads on the general undesirability of 
> using SIP to transport large content files around. Further, 
> on a 3GPP-specific note, this approach would make it much 
> more difficult to get any kind of reliable idea of the 
> bandwidth/QoS requirements for the signalling-specific radio 
> resource. Whilst you may wish to allow this resource to be 
> used for content as well, I do not think people should be 
> mandated to do this.
> Finally, one of your requirements is to cope with devices of 
> various form-factors/capabilities and the ability to render 
> multi-media content is one capability which varies greatly 
> from device to device - I really do not want to send a video 
> clip even once to a device which can't render it.
> I do not see what the big deal is with including a URI for 
> any such content in the Presence Document. This has so many 
> advantages:
> a) The content is only sent when it changes (even with your 
> proposal, it is sent at least every time a watcher subscribes)
> On charging you solution is to require that this data is 
> charged in the same way as the rest of SIP signalling - but 
> this solution does not imply that the data is carried *in* 
> SIP signalling. If this is what you want to do, then just 
> allow HTTP requests to a local HTTP-proxy (designated for 
> this purpose) to use the signalling resource.
> Until we've bottomed out this in-line content question, I 
> don't see how we can conclude on whether partial 
> notifications are valuable or not.
> Regards, 
> Mark

---

From: [email-masked]
Date: Thu, 6 Feb 2003 14:41:30 +0200

Hi,

Inline.

[snip]
>  > Also, I don't know whether the notify/fetch is actually a 
> feature of
>  > MMS - or a bug (meaning that since there is no way to 
> really push the
>  > content all the way, there's a need to first notify). At least my
>  > phone currently doesn't prompt me, but goes and fetches the MM
>  > automagically.
> 
> A bug? You must be kidding! I think this is a critical 
> feature! Are you 
> telling me that you REALLY want to ALWAYS pay for someone 
> else picture 
> of their kids that they put in a presence doc or IM???? Maybe 
> your phone 
> always pulls it, but perhaps its time to get a new phone ;)

Aha! I think we're in the core of the charging problem here. The MMS charging model is "sender pays". So receiving an MMS is always free for me. With this model, the only inconvenience experienced by me is having to delete those family pics of my friends, since receiving them had flat rate or no charging on it.

Anyway, I agree we should probably try to write up the problem description in a clearer way. It seems that the authorization/storage concerns aren't that major after all, so the essence is probably this charging issue.

Cheers,
Aki

---

From: [email-masked]
Date: Thu, 6 Feb 2003 16:01:59 +0200

Hi,
 
One issue seems to be that how does CI (using HTTP) help in case of
compression? What I mean is that you probably want to compress all the
protocol data to and from your UA. If compression fails with SIP how is
it better with HTTP? Or are you saying that there should not be any
compression for HTTP? And if you then want to compress HTTP you probably
need dictionaries for HTTP and also your HTTP server and UA would need
to support it. 
 
- Mikko 

	-----Original Message-----
	From: ext Mark Watson [mailto:[email-masked]] 
	Sent: 05 February, 2003 20:20
	To: Niemi Aki (NMP/Helsinki); [email-masked]
	Subject: RE: [Simple] New I-Ds on partial notification

	Aki, 

	Well, it depends on the compression algorithm used. Certainly
the simple ones do little more that send a string of <offset,length>
pairs to reference strings which occured earlier in the data stream - of
course with some way of escaping to literal data. So, certainly, large
in-band binary content will reduce the effectiveness of these schemes.

	You could mitigate this by ensuring that the static dictionary
never goes out of view, or, for example, only storing the first X octets
of each message, where X is chosen to usually cover the headers and SDP.

	Other schemes build up a dictionary of codewords e.g. in LZW
then the codebook is built up by allocating a new codeword for the
previous phase plus the next character. Common phrases will end up
appearing in more codewords and in longer referenced strings. I think
this would not be so affected by raw binary data, since this wouldn't
disrupt the codebook already built.

	However, I'm not so sure this is the best scheme for SIP
signalling, since it takes quite a while to build up the codebook. You
want, for example, to be referencing back to the entire Request URI when
it appears again in the To field a few octets later, and then do the
same in subsequent requests/responses - not sure LZW would get you this.

	DEFLATE, if I remember correctly, does LZW & then Huffman
encodes the result. 

	In my personal opinion, binary content in SIP messages,
including the Caller Photo & Multimedia Messages is a bad thing per se
and Content Indirection should always be used. (As Jonathan mentioned,
the existing MMS does not send the content with the notification of the
message - you have to fetch it).

	Having said that, referencing out from the Presence Document to
something which might be at a URL or might be in another MIME part of
the Notification might provide a way forward - of course I'd still say
that these other MIME parts should be Content-Indirected :-), but at
least you have solved the encoding problem and brought the compression
problems into the same space as Caller-photos etc.

	...Mark 

	> http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres

	> info-deliv-reqs-00.txt 
	> http://www.ietf.org/internet-drafts/draft-lonnofors-simple-par

	> tial-notify-00.txt

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 6 Feb 2003 14:17:15 -0000

Mikko,

I would expect SIGCOMP compressors to be highly optimised for SIP. You can
achieve extremely high compression gains if you choose the right compressor.
My point below was not just that arbitrary data included inline would not
compress well, but that the presence of this data might reduce the
effectiveness of the compression on the rest of the SIP messages, because of
the effect this arbitrary data has on the (dynamic) dictionary.

A key feature of SIP messages is that they contain a few long strings which
are then repeated in their entirity a few lines later or in later messages.
Basically these are the URIs which appear in To/From/Via/Route/Record-Route
but there are also things like the pre-conditions attributes in the SDP
which are very verbose and may be repeated for every media line.

A compression scheme which can efficiently reference these strings appearing
earlier in the message, or in a previous message, will work well for SIP. If
there's 10k of in-line content in a message which blows out the dynamic
dictionary, then you may lose this ability to reference. (But then if
there's 10k of content in the message I'm not so sure why you care about
reducing the SIP message headers from 900 to 400 octets, or whatever.)

It would be wise to compress HTTP traffic as well - in fact it would not be
unwise to compress all traffic on the wireless link (I think most analog
modems use some form of compression on the low-bandwidth links that they
provide) using some generic compression scheme.

Compression for HTTP (or generic) traffic wouldn't need a specific
dictionary. There aren't enough HTTP Headers, compared to the size of the
arbitrary HTTP bodies, for it to be worth bothering. SIP is different,
because we expect the majority of octets of most messages to be SIP headers
or SDP. If you put large in-line content in SIP, you make it just like HTTP
in this respect - you might as well use generic compression at the link
layer instead of SIGCOMP.

...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 06 February 2003 14:02
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]; [email-masked]
Subject: RE: [Simple] New I-Ds on partial notification

Hi,
 
One issue seems to be that how does CI (using HTTP) help in case of
compression? What I mean is that you probably want to compress all the
protocol data to and from your UA. If compression fails with SIP how is it
better with HTTP? Or are you saying that there should not be any compression
for HTTP? And if you then want to compress HTTP you probably need
dictionaries for HTTP and also your HTTP server and UA would need to support
it. 
 
- Mikko 
-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]] 
Sent: 05 February, 2003 20:20
To: Niemi Aki (NMP/Helsinki); [email-masked]
Subject: RE: [Simple] New I-Ds on partial notification

Aki,