Subject: [Simple] RE: Presence filtering idea

From: [email-masked]
Date: Thu, 12 Jun 2003 17:03:17 +0300

Moving the discussion to the mailing list.

Comments inline...

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, June 11, 2003 11:29 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; Niemi Aki (NMP/Helsinki)
> Subject: Re: Presence filtering idea
> 
> 
> Actually, the recent discussions amongst the "what is a tuple" design 
> team have convinced me further that xpath is the wrong thing 
> for filters.
> 
> The reason is, that the same information can appear within the 
> presence document in a lot of different possible places, depending on 
> the "axes" along which the presence agent chooses to organize the 
> data. We have discussed multiple different views of a presentity - a 
> device-centric view (where each tuple represents a device), a service 
> centric view (where each tuple represents a service, like voice or 
> IM), and a media centric view (where each tuple represents a media 
> type - audio, video, messaging). The same piece of information - say, 
> whether I am in a call or out of a call, might appear in different 
> places in different ways depending on how the document is structured.

I still don't understand how the subscriber can render the information given in the tuple of the NOTIFY if it receives the info in an XML format it does not understand, especially info it specifically asked for in a filter.

Someone in the interim suggested that you can just show the whole XML document to the user, but that's not feasable, especially for automata.

eg: I want to know when Jonathan is available for IM so that I automatically send him an IM to call me. Using Jonathan's idea of not using XPath, I need to, for example, use the keyword "im" in the filter.

Jonathan now become available for IM and I receive the IM info in a device tuple that looks like:

<tuple id="3lkjerw">
   <IM>OPEN</IM>
</tuple>

But my device only understands it in the form that the tuple represents a service:

<tuple id="kdfaklk">
   <rpids:label>IM</label>
   <basic>OPEN</basic>
</tuple>

Either there must be a standardised way of representing something, or this automaty will not work.

Using XPath as the indicator of what the subscriber exactly wants, the server can probably construct the tuple is the indicated format. 

The alternative is that the subscriber has to inform the compositor the representation of tuples it accepts. We we need to go down that path?

Also, one more thing to point out: filtering is not just for presence. It is for any event package and the solution needs to be generic enough. I say we fix the tuple problem instead of making other solutions that are generic more complicated.

> 
> Furthermore, you run into issues when you introduce 
> dependencies. Lets 
>   say a PA knows whether the phone is in-call or out-of-call. The 
> filter says that you want to know call state. If the PA produces a 
> device-centric document, it might decide to omit in-call or 
> out-of-call and instead represent this information by setting the 
> status to busy. In a service centric view, the status might 
> instead be 
> reflected in an actual in-call/out-of-call attribute.
> 
> So, the heart of the issue here - do we think filters should also 
> apply to the data used as INPUTs to a composition process, or not?

No, filters are only applied to the already composed NOTIFY contents.

Regards,
Hisham

> 
> -Jonathan R.
> 
> [email-masked] wrote:
> > Henning,
> > 
> > I don't think you have read the proposed draft carefully, or at
> > all. I urge you to spend a few minutes looking through it.
> > 
> > XPath is only one small part of the overall solution. It is used
> > purely for pointing out an element in an XML document. There are
> > other elements and attributes in the proposed filter MIME that make
> > the proposed filtering solution complete (or almost complete).
> > 
> > I don't understand Aki's proposal beyond the fact that it is only
> > another way of expressing a filter. The fact remains that you want
> > to filter out parts of an xml document. We can expand filtering to
> > include such solution, but it is not a replacement.
> > 
> > I acknowledge Jonathan's comments in the interim about a URI
> > identifying to whom the filter is. We will tackle that (borrowing
> > some ideas from XCAP authorization list solution when released).
> > 
> > Regards, Hisham
> > 
> > 
> >> -----Original Message----- From: ext Henning Schulzrinne
> >> [mailto:[email-masked]] Sent: Wednesday, June 11, 2003 12:56
> >> AM To: Jonathan Rosenberg Cc: Niemi Aki (NMP/Helsinki); Khartabil
> >> Hisham (NMP/Helsinki) Subject: Re: Presence filtering idea
> >> 
> >> 
> >> My remark as not a disagreement, just an elaboration (or to make
> >> sure that I understood what you were saying...).
> >> 
> >> Jonathan Rosenberg wrote:
> >> 
> >> 
> >>> I'm confused - I agree with you. I dont like Xpath for filters,
> >>> and strongly argued in favor of a semantic model during the
> >> 
> >> interim. The
> >> 
> >>> idea was to use the XML document format for authorization
> >> 
> >> policy as the
> >> 
> >>> filter format as well, to unify them.
> >>> 
> >>> -Jonathan R.
> >>> 
> >>> Henning Schulzrinne wrote:
> >>> 
> >>> 
> >>>> I actually find XPATH in this context less expressive and
> >> 
> >> needlessly
> >> 
> >>>> more complex than a simple boolean expression, but that's
> >> 
> >> a syntax issue.
> >> 
> >>>> Jonathan Rosenberg wrote:
> >>>> 
> >>>> 
> >>>>> Aki,
> >>>>> 
> >>>>> This is exactly the kind of thing I meant by a semantic
> >> 
> >> filter. Other
> >> 
> >>>>> types of things would be to specify the actual status
> >> 
> >> elements within
> >> 
> >>>>> the namespace, and to specify the types of tuples which
> >> 
> >> are desired
> >> 
> >>>>> (this is, of course, presuming we can get some agreement
> >> 
> >> on what a
> >> 
> >>>>> tuple is...).
> >>>>> 
> >>>>> The current data manipulation requirements draft spells out
> >>>>> the specific semantic authorization operations that are
> >> 
> >> desired, many of
> >> 
> >>>>> which map into filters.
> >>>>> 
> >>>>> -Jonathan R.
> >>>>> 
> >>>>> [email-masked] wrote:
> >>>>> 
> >>>>> 
> >>>>>> Hi,
> >>>>>> 
> >>>>>> I wanted to circulate a wild idea I got after the
> >>>>>> syntactic vs. semantic discussion at the interim.
> >>>>>> 
> >>>>>> What if we do filtering based on namespaces?
> >>>>>> 
> >>>>>> A filter would simply be a list of URNs, defining the
> >>>>>> namespaces that are interesting to the subscriber. A bare
> >>>>>> bones PIDF filter would define cpim-pidf (could be the
> >>>>>> default) as the only allowed namespace, effectively
> >>>>>> stripping out everyting else - standard or proprietary.
> >>>>>> The subscriber could allow more namespaces based on what
> >>>>>> it supports.
> >>>>>> 
> >>>>>> I think this might be a pretty nice middle ground
> >> 
> >> between a purely
> >> 
> >>>>>> syntactical approach (XPath-based) and the semantic
> >> 
> >> approach (This
> >> 
> >>>>>> pending of course Jonathan's proposal ;). Also, I think
> >> 
> >> this would
> >> 
> >>>>>> be a nice way to align the authorization and filtering
> >>>>>> solutions.
> >>>>>> 
> >>>>>> Thoughts?
> >>>>>> 
> >>>>>> Cheers, Aki
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>> 
> >> 
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Fri, 13 Jun 2003 11:21:49 +0300

> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, June 13, 2003 4:45 AM
> Cc: [email-masked]; Niemi Aki (NMP/Helsinki); [email-masked]
> > I still don't understand how the subscriber can render the
> > information given in the tuple of the NOTIFY if it receives the info
> > in an XML format it does not understand, especially info it
> > specifically asked for in a filter.
> > 
> > Someone in the interim suggested that you can just show the 
> whole XML
> > document to the user, but that's not feasable, especially for
> > automata.
> 
> Not for automata, but any recent browser will render XML, of 
> any schema, 
> in a reasonably human-readable format.

Maybe you, me and others on the list can read the XML document and figure out what information it carries, but most people can't. What does an element called <basic> mean to an average user?

Referring to the example I presented in an earlier email, I cannot automate sending an IM to someone when he comes online unless my terminal understands the format of the XML document it receives and consequently sends the IM. Do you want to eliminate such automated feature? I'm not happy when saying that any recent Brower can render XML in a human-readable format, I want to automate things.

> 
> > Either there must be a standardised way of representing 
> something, or
> > this automaty will not work.
> 
> Can't speak for others, but I'm not suggesting that we allow 
> any random 
> presence format. I'm just not convinced that a generic XPath 
> mechanism 
> is the most intuitive way of representing this information. It is 
> necessary if we assume two things
> 
> - events (including presence) can be any valid XML schema 
> that's agreed 
> upon by both sides

I'm not convinced that it can done otherwise. Again, the client of the resulting XML document is not necessarily a human. The notifier must send the requested information in a format the subscriber understands. 2 reasons:

- Automata
- I don't want my application client to pop up my web Brower every time it doesn't understand how to fit the XML document into a pre-defined GUI. I want my application server to send info in a format that the application client was build to handle and elements in doesn't understand.

> 
> or
> 
> - events are more than a simple hierarchy.
> 
> Otherwise, something much more intuitive like
> 
> privacy > 'public' and media contains 'audio'
> 
> would do the trick, somewhat similar to the Sieve.

Along with the arguments I present above, I would like to re-state that the proposal we put forward is not just presence specific, its a generic filtering solution for any event package.

> 
> > The alternative is that the subscriber has to inform the compositor
> > the representation of tuple it accepts. We we need to go down that
> > path?
> 
> That's a false alternative; see above for something that is neither 
> XPath nor random event documents.

Remember that every other event package has a fixed XML format with well defined representation of information, it is the tuple that is causing the problems. Examine winfo for example.

> 
> > generic enough. I say we fix the tuple problem instead of making
> > other solutions that are generic more complicated.
> 
> I don't see that there is a tuple problem to fix. The current 
> capabilities description in RPIDS is unnecessarily messy, but I think 
> there are better solutions that explicitly extend the XML definition 
> rather than using the cop-out of capabilities in tags. (At 
> least in my 
> opinion, capabilities should be first-class citizens, not 
> second-class 
> ones, living lowly string existences.)

Perhaps I'm arguing this in the wrong thread, but I don't think representing the same info in different ways is a good solution. IM info should be represented in the same way no matter what the tuple itself represents.

Regards,
Hisham

---

From: [email-masked]
Date: Mon, 16 Jun 2003 10:50:38 +0300

> Sent: Friday, June 13, 2003 9:43 PM
> Subject: [Simple] Re: Presence filtering idea
> 
> 
> > Maybe you, me and others on the list can read the XML document and 
> > figure out what information it carries, but most people can't. What 
> > does an element called <basic> mean to an average user?
> > 
> > Referring to the example I presented in an earlier email, I cannot 
> > automate sending an IM to someone when he comes online unless my 
> > terminal understands the format of the XML document it receives and 
> > consequently sends the IM. Do you want to eliminate such automated 
> > feature? I'm not happy when saying that any recent Brower 
> can render 
> > XML in a human-readable format, I want to automate things.
> 
> Nobody here, I believe, is suggesting some unstructured or 
> non-standardized presence or event document. I certainly never did. I 
> simply noted that extensions, while not accessible to automatons, may 
> still be accessible to humans. Certainly, most of the tags in 
> the RPIDS 
> description are pretty obvious. This is a non-issue, so we should 
> probably not waste additional electrons on this.
> 
> > I'm not convinced that it can done otherwise. Again, the client of 
> > the resulting XML document is not necessarily a human. The notifier 
> > must send the requested information in a format the subscriber 
> > understands. 2 reasons:
> 
> Again, this is not in contention. You are not understanding 
> my concern. 
> The issue is not the standardization of the presence format, 
> but rather 
> the language used to express filtering. I'm not convinced 
> that XPath is 
> necessarily the most appropriate language.
> 
> > 
> > Along with the arguments I present above, I would like to re-state 
> > that the proposal we put forward is not just presence 
> specific, its a
> >  generic filtering solution for any event package.
> 
> Your concerns above do not apply; your concerns here only apply if we 
> assume that event description are arbitrarily structured XML, 
> as I noted 
> in my original message.

My concern was about the comment that was made that a presence state can be expressed in many different standardised ways depending on what a tuple represents. My argument was that either the client needs to understand all the standardised ways of representing a certain presence state, or the compositor has to know/agree with the client.

In both cases, I don't see the difference between representing the filter like:

media="audio"

or in xpath //*[/media="audio"

/Hisham

---

From: [email-masked]
Date: Mon, 16 Jun 2003 10:50:38 +0300

media="audio"

/Hisham