Subject: [Simple] RE: Presence filtering idea

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

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, June 13, 2003 4:45 AM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; Niemi Aki (NMP/Helsinki); [email-masked]
> Subject: Re: Presence filtering idea
> 
> 
> [email-masked] wrote:
> 
> > 
> > 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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Jun 2003 14:43:22 -0400

[email-masked] wrote:

> 
> 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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Jun 2003 14:43:22 -0400