Subject: RE: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt

From: [email-masked]
Date: Sun, 17 Nov 2002 21:21:56 +0200

Hi,

I would be happy with a more generalized solution than what is being discussed in my draft. I think SIMPLE data manipulation and conference policy control protocol should be solved within the same framework. Using XML schemas for manipulated objects (such as lists) and using XPath etc. to implement generic manipulation operations would be a good candidate. Actually, I think XPath might be a good solution to presence event filtering as well.

The question now is how to go forward. I wrote the list manipulation 'semantics' draft, because people were saying that it is not possible to pick a particular solution, such as XML or SOAP, straight away. Maybe we should first make even some higher level decisions, such as whether to follow PROTOCOL OPTION 1, 2 or 3 from Jonathan's mail. 

I'll try to raise some discussion about this during my presentation in SIMPLE. Also, I'll try to find out how many people are actually willing to allocate some time to work on this, to have a commonly agreed approach within that group. There hasn't been much discussion on the mailing list.

Markus 

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 16 November, 2002 08:20
> To: Isomaki Markus (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] FW: I-D
> ACTION:draft-isomaki-simple-list-man-sem-00.txt
> 
> 
> This draft is a good start.
> 
> I would very much like to do this as generally as possible. Clearly, 
> there are a number of different ways to design a protocol to meet the 
> requirements in the data-req draft. They range from the 
> totally specific 
> to totally general:
> 
> * PROTOCOL OPTION 1: We design a protocol that JUST does whats in the 
> requirements doc, nothig more, nothing less. Its simple, but it only 
> works for buddy lists and authorization policy. It won't work for 
> conference policy, for example.
> 
> * PROTOCOL OPTION 2: Markus' draft. Generalize option 1 a 
> bit. Focus on 
> lists of things, and define a general protocol for creating, 
> modifying 
> and managing lists. Works for buddy lists and conferencing 
> too, so long 
> as all they do is manage lists.
> 
> * PROTOCOL OPTION 3: Generalize Markus' draft further. Assume that 
> anything we want to manipulate can be represented in XML. Conference 
> policies might be modelled as really complex XML documents. Media 
> policies too. A buddy list is an XML document. And so on. The 
> protocol, 
> then, is a general tool for remote editing of XML documents. Using 
> things like XPath, you can address a particular node, add elements, 
> modify them, etc. The underlying application (conferencing, 
> buddy list) 
> validates the changes against its schemas, and assignes 
> semantics to the 
> documents.
> 
> 
> There are probably more sub-options between 2 and 3. For 
> example, we cna 
> introduce restrictions on the types of XML documents we can 
> manipulate, 
> the types of changes we can make, and so on.
> 
> Where do draw the line?
> 
> Clearly, we want something simple so that we can be done 
> soon. Simple is 
> always good.
> 
> However, I would also like a single protocol that can meet the 
> requirements here, AND the requirements for conference policy control 
> and media policy control that are evolving in SIPPING. 
> Conference policy 
> is complex enough that a simple list won't suffice. So, I 
> think we need 
> a bit more that what Markus has defined.
> 
> Thoughts?
> 
> -Jonathan R.
> 
> [email-masked] wrote:
>  > Hi,
>  >
>  > The following draft is now available in the I-D 
> directories. It is an
>  > initial attempt to specify a list management protocol on 
> an abstract
>  > level (only semantics, no syntax). The proposal is made 
> based on the
>  > requirements stated in "draft-ietf-simple-data-req-00". 
> The draft is
>  > still quite drafty, but the main points should be visible.
>  >
>  > The main idea is that many applications (for instance presence and
>  > conferencing) require lists that should be configurable by a client
>  > terminal. It would be useful to define a standard protocol 
> to handle
>  > list manipulation (for SIP-applications), so that it could be
>  > "plugged in" to any application needing it.
>  >
>  > I hope comments to the approach and to the actual abstract 
> protocol.
>  > If this is a good enough start, it could be used as a 
> basis for a WG
>  > document. After that would be reasonably stable, a mapping to some
>  > real syntax could be made and that specifation should be 
> in standards
>  > track.
>  >
>  > Markus
>  >
>  >
>  >> -----Original Message----- From: ext [email-masked]
>  >> [mailto:[email-masked]] Sent: 04 November, 2002 17:05
>  >> Subject: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
>  >>
>  >>
>  >> A New Internet-Draft is available from the on-line Internet-Drafts
>  >> directories.
>  >>
>  >>
>  >> Title		: Semantic Description of SIMPLE List 
> Manipulation
>  >> Operations Author(s)	: M. Isomaki et al. Filename	:
>  >> draft-isomaki-simple-list-man-sem-00.txt Pages		
> : 13 Date		:
>  >> 2002-11-1  In SIMPLE based presence and messaging applications, it
>  >> is necessary for  the user to be able to configure a number of
>  >> pieces of information. One of the most common types of information
>  >> is a list of URIs. List management is useful outside the scope of
>  >> SIMPLE as well, for instance in conferencing. There are many
>  >> reasons why it would be beneficial to manage the lists in 
> a similar
>  >> fashion regardless of the application. Before the selection of the
>  >> actual protocol(s) to manage the lists there is a need to describe
>  >> their semantics on an abstract level. This document proposes the
>  >> semantics for SIMPLE list manipulation protocol.
>  >>
>  >> A URL for this Internet-Draft is:
>  >> http://www.ietf.org/internet-drafts/draft-isomaki-simple-list-
>  >
>  > man-sem-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-isomaki-simple-list-man-sem-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-isomaki-simple-list-man-sem-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.
>  >
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 00:57:28 -0500

[email-masked] wrote:
 > Hi,
 >
 > I would be happy with a more generalized solution than what is being
 > discussed in my draft. I think SIMPLE data manipulation and
 > conference policy control protocol should be solved within the same
 > framework. Using XML schemas for manipulated objects (such as lists)
 > and using XPath etc. to implement generic manipulation operations
 > would be a good candidate. Actually, I think XPath might be a good
 > solution to presence event filtering as well.
 >
 > The question now is how to go forward. I wrote the list manipulation
 > 'semantics' draft, because people were saying that it is not possible
 > to pick a particular solution, such as XML or SOAP, straight away.
 > Maybe we should first make even some higher level decisions, such as
 > whether to follow PROTOCOL OPTION 1, 2 or 3 from Jonathan's mail.

I think thats a good idea. I don't think we really need to go through a 
formal process of defining a semantics spec, and then choosing a 
protocol. If we can get general agreement on an approach, I think the 
protocol itself falls out of that.

-Jonathan R.