Subject: [Simple] Comments on Pres-Filter-Reqs-03

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Mon, 2 Feb 2004 06:30:05 -0600

HI,

I have few questions/comments on the presence filter requirements 03 draft:

Req C1 : It does not seem that this is a requirment on the watcher, rather the presence server. Otherwise, I dont get that one.

Req C6: I wonder the usefulness of the requirement. It seems more natural to say what you want rather what you dont want to see. 

Req D1 & Req I4 :  I conclude from those 2 requirements that there can be multiple filters within a single SUBSCRIBE. If that is the case, I would like to understand whether the presence server is expected to ensure that the 2 filters dont contradict each other.
   
Req G7: Is this a watcher requirement or a presence server requirement. 

Req. I1: This is a presence server requirement. Also, I dont understand the reasons for it and what would the PS send the watcher in this case.

 Req I6: I dont understand that one. May be wording changes can clarify it a bit better,

Rgd/gf
Ericsson Canada 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: [email-masked]
Date: Tue, 3 Feb 2004 12:03:11 +0200

George,

Thanks for the comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext George Foti (QC/EMC)
> Sent: 02.February.2004 14:30
> To: [email-masked]
> Subject: [Simple] Comments on Pres-Filter-Reqs-03
> 
> 
> HI,
> 
> Req C1 : It does not seem that this is a requirment on the 
> watcher, rather the presence server. Otherwise, I dont get that one.

You are correct.

> 
> Req C6: I wonder the usefulness of the requirement. It seems 
> more natural to say what you want rather what you dont want to see. 

The requirement states what you want.
> 
> Req D1 & Req I4 :  I conclude from those 2 requirements that 
> there can be multiple filters within a single SUBSCRIBE. If 
> that is the case, I would like to understand whether the 
> presence server is expected to ensure that the 2 filters dont 
> contradict each other.

Yes it is.

> Req G7: Is this a watcher requirement or a presence server 

Server.

> 
> Req. I1: This is a presence server requirement. Also, I dont 
> understand the reasons for it and what would the PS send the 
> watcher in this case.

Polite blocking. You might not want to tell a watcher that he's not allowed to see certain parts of your presence information. So you accept the filter, but give false information.

> can clarify it a bit better,

An RLS fans out subscriptions. If there is a filter for someone is domain1.com, the RLS should not forward that filter to domian2.com.

/Hisham

> 
> Rgd/gf
> Ericsson Canada 
> 
> 
> This communication is confidential and intended solely for 
> the addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has 
> been sent to you in error, please notify the sender by 
> replying to this transmission and delete the message without 
> disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data 
> corruption, interruption, unauthorized amendment, tampering 
> and viruses, and we only send and receive e-mails on the 
> basis that we are not liable for any such corruption, 
> interception, amendment, tampering or viruses or any 
> consequences thereof.
>

---

From: [email-masked]
Date: Tue, 3 Feb 2004 12:03:11 +0200

George,

Thanks for the comments.

You are correct.

Yes it is.

Server.

/Hisham

---

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Tue, 3 Feb 2004 06:24:07 -0600

I have more questions/comments Hisham,

1) I initially understood that these are requirments on the watcher and not the PS. Now there are clearly a mix of both which is okay, as long as the scope clearly states that, and that it is clear from the requirement whether this is a PS or a watcher requirement. With that in mind, Req C1 needs to be clarified, as it incorrect the way it is currently stated.

2) You did not sepcifically address the behavior of the PS when it comes to a SUBSCRIBE holding multilple filters.
Is the PS suppose to check that the filters dont contradict each other, or is this a watcher problem, or even an implmentation issue
I would like to see the requirement clearer in that regard.

3) You misunderstood my comment on Req C6, so I will reword - I wonder the usefulness of the requirement. It seems more natural for a watcher to state in a filter what he would like to receieve, rather what he does not want to receieve.

4) Finally, I would like to add a requirement in which the watcher indicates his *willingness* to receive binary XML. This allows PS to conveny presence information in that format, if it supports that, but does not oblige compliance.

Thanks.

/gf

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2004 5:03 AM
> To: George Foti (QC/EMC); [email-masked]
> Subject: RE: [Simple] Comments on Pres-Filter-Reqs-03
> 
> 
> George,
> 
> Thanks for the comments.
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > ext George Foti (QC/EMC)
> Polite blocking. You might not want to tell a watcher that 
> he's not allowed to see certain parts of your presence 
> information. So you accept the filter, but give false information.
> 
> > 
> An RLS fans out subscriptions. If there is a filter for 
> someone is domain1.com, the RLS should not forward that 
> filter to domian2.com.
> 
> /Hisham
> 
> > 
> > Rgd/gf
> > Ericsson Canada 
> > 
> >

---

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Tue, 3 Feb 2004 06:24:07 -0600

Thanks.

/gf

---

From: [email-masked]
Date: Tue, 3 Feb 2004 14:43:12 +0200

> From: ext George Foti (QC/EMC) [mailto:[email-masked]]
> Sent: 03.February.2004 14:24
> To: Khartabil Hisham (Nokia-TP/Helsinki); [email-masked]
> 1) I initially understood that these are requirments on the 
> watcher and not the PS. Now there are clearly a mix of both 
> which is okay, as long as the scope clearly states that, and 
> that it is clear from the requirement whether this is a PS or 
> a watcher requirement. With that in mind, Req C1 needs to be 
> clarified, as it incorrect the way it is currently stated.

These are requirements for the filtering solution. Some things are required by the client, others by the server
> 
> 2) You did not sepcifically address the behavior of the PS 
> when it comes to a SUBSCRIBE holding multilple filters.
> Is the PS suppose to check that the filters dont contradict 
> each other, or is this a watcher problem, or even an 
> implmentation issue

You are tapping into the solution space. New versions of the solution drafts will be available shortly.
> 
> 3) You misunderstood my comment on Req C6, so I will reword - 
> I wonder the usefulness of the requirement. It seems more 
> natural for a watcher to state in a filter what he would like 
> to receieve, rather what he does not want to receieve.

A watcher can ask for information to be included in the notification using a namespace. Allowing the watcher to exclude elements that are in the namespace that are of no interest to him is what this requirement is talking about.

> 
> 4) Finally, I would like to add a requirement in which the 
> watcher indicates his *willingness* to receive binary XML. 
> This allows PS to conveny presence information in that 
> format, if it supports that, but does not oblige compliance.

Excuse my ignorance, but I don't know what binary XML is. In any case, I think this is a general issue, not specific for requests carrying filters.

Thanks again for the comments.
Hisham

---

From: [email-masked]
Date: Tue, 3 Feb 2004 14:43:12 +0200

---

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Tue, 3 Feb 2004 11:19:49 -0600

>Excuse my ignorance, but I don't know what binary XML is. In any case, I think this is a general issue, not specific for requests carrying filters.

The VBXML is a WAP specification.  The link is:

http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-192-wbxml-20010725-a.pdf

Its applicability is for presence information returned from PS and nothing else as you seem to state. Presence traffic that can be generated can be quite large, and if you include lists, it can cause bottle necks on radio links.
This requirment provides an option for devices that can deal with binary XML to indicate that.
I dont see what is the problem with including such a requirement. 
Otherwise, there must be some supportin the draft for requirements to deal with vendor specific options in the filter, that a PS can choose to ignore, it it does not understand. 

Rgds/gf

> Sent: Tuesday, February 03, 2004 7:43 AM
> These are requirements for the filtering solution. Some 
> things are required by the client, others by the server
> > 
> You are tapping into the solution space. New versions of the 
> solution drafts will be available shortly.
> > 
> A watcher can ask for information to be included in the 
> notification using a namespace. Allowing the watcher to 
> exclude elements that are in the namespace that are of no 
> interest to him is what this requirement is talking about.
> 
> > 
> Excuse my ignorance, but I don't know what binary XML is. In 
> any case, I think this is a general issue, not specific for 
> requests carrying filters.
>

---

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Tue, 3 Feb 2004 11:19:49 -0600

Rgds/gf

---

From: [email-masked]
Date: Tue, 3 Feb 2004 22:12:13 +0200

Hi George,

VBXML support does not need to be part of filtering. You could indicate support for it in Accept header in SUBSCRIBE. See for instance Chapter 4.2 in partial presence notifications draft (http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-01.txt). I guess for this you would need to define the correct VBXML coded PIDF content type first, though.

Also remember that Signaling Compression can be used to compress presence information, or other SIP payloads, over radio links, and indeed the partial notification draft is also available. Lastly, you could use content indirection to avoid overloading the signaling bearer, depending on what kind of SIP network you are on.

Markus

> Sent: 03 February, 2004 19:20
> http://www.openmobilealliance.org/tech/affiliates/LicenseAgree
> ment.asp?DocName=/wap/wap-192-wbxml-20010725-a.pdf
> 
> Its applicability is for presence information returned from 
> PS and nothing else as you seem to state. Presence traffic 
> that can be generated can be quite large, and if you include 
> lists, it can cause bottle necks on radio links.
> Otherwise, there must be some supportin the draft for 
> requirements to deal with vendor specific options in the 
> filter, that a PS can choose to ignore, it it does not understand. 
> 
> Rgds/gf
>   
> 
>

---

From: [email-masked]
Date: Tue, 3 Feb 2004 22:12:13 +0200

Hi George,

Markus

---

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Wed, 4 Feb 2004 06:53:07 -0600

Thanks Markus, that addresses my requirement.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2004 3:12 PM
> To: George Foti (QC/EMC); [email-masked]; [email-masked]
> VBXML support does not need to be part of filtering. You 
> could indicate support for it in Accept header in SUBSCRIBE. 
> See for instance Chapter 4.2 in partial presence 
> notifications draft 
> (http://www.ietf.org/internet-drafts/draft-ietf-simple-partial
> -notify-01.txt). I guess for this you would need to define 
> the correct VBXML coded PIDF content type first, though.
> 
> Also remember that Signaling Compression can be used to 
> compress presence information, or other SIP payloads, over 
> radio links, and indeed the partial notification draft is 
> also available. Lastly, you could use content indirection to 
> avoid overloading the signaling bearer, depending on what 
> kind of SIP network you are on.
> 
> Markus
> 
>

---

From: "George Foti (QC/EMC)" <[email-masked]>
Date: Wed, 4 Feb 2004 06:53:07 -0600