Subject: [Simple] unsubscribe

From: [email-masked]
Date: Tue, 29 Oct 2002 15:54:52 -0600

----- Original Message -----
Wrom: CUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRK
To: <[email-masked]>
Sent: Tuesday, October 29, 2002 11:01 AM
Subject: simple digest, Vol 1 #547 - 10 msgs

> Send simple mailing list submissions to
> [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> or, via email, send a message with subject or body 'help' to
> [email-masked]
>
> You can reach the person managing the list at
> [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of simple digest..."
>
>
> Today's Topics:
>
>    1. Re: Re: draft-olson-simple-publish-01.txt (Sean Olson)
>    2. Re: Re: draft-olson-simple-publish-01.txt (Paul Kyzivat)
>    3. RE: collection template (Adam Roach)
>    4. FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
([email-masked])
>    5. Comment to draft-olson-simple-publish-01.txt
([email-masked])
>    6. A omment to draft-olson-simple-publish-01 ([email-masked])
>    7. I-D ACTION:draft-campbell-simple-im-sessions-00.txt
([email-masked])
>    8. I-D ACTION:draft-campbell-simple-cpimmsg-sessions-00.txt
([email-masked])
>    9. Re: FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt (Paul
Kyzivat)
>   10. IETF55 Agenda Requests (Robert Sparks)
>
> --__--__--
>
> Message: 1
> Date: Mon, 28 Oct 2002 09:00:24 -0800 (PST)
> Wrom: JVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAA
> Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt
> To: Paul Kyzivat <[email-masked]>, Simple
<[email-masked]>
>
> The analogy breaks down in situations that need
> more persistence of the stream identifier. If Call-ID
> where to persist across all requests, across reboots,
> and potentially across devices, then it would be a
> perfect fit :) It may be that we find a better way
> to accomplish this. The "Stream" header is a first
> shot at satisfying the need for a compositor to
> identify the source of a publication.
>
> Thanks,
> Sean Olson
> Microsoft
>
>
> --- Paul Kyzivat <[email-masked]> wrote:
> > I question the need for the Stream header. Its use
> > seems entirely analogous to the use of a common
> > Callid header in REGISTER requests. Why is it
> > necessary to introduce a new header for PUBLISH when
> > it wasn't necessary for REGISTER?
> >
> > Paul
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
>
> --__--__--
>
> Message: 2
> Date: Mon, 28 Oct 2002 14:17:29 -0500
> Wrom: LPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQB
> To: Sean Olson <[email-masked]>
> CC: Simple <[email-masked]>
> Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt
>
>
>
> Sean Olson wrote:
> >
> > The analogy breaks down in situations that need
> > more persistence of the stream identifier. If Call-ID
> > where to persist across all requests, across reboots,
> > and potentially across devices, then it would be a
> > perfect fit :)
>
> Hmm. If that analogy doesn't hold then it would be helpful to have a more
complete description of the semantics of a stream. I guess the discussion of
section 1.1.4 Publisher Instance is intended to provide this. But it doesn't
line up especially well with the definition of Stream in 3.3. Section 3.3
focuses on providing a context within which to process messages in order,
while 1.1.4 focuses on distinct publishing instances. From your comments,
you suggest that a distinct instance might not always reside on the same
device. Once you say that, the possibility arises that you might have two
physical devices simultaneously claiming to have the same logical identity.
And that messes up the suggested means of ordering messages within a stream.
Actually, even moving a stream from one device to another might cause
ordering to be messed up if there is significant clock skew.
>
> Based on the available descriptions, I don't yet understand what I might
want to use this feature for. You authors obviously have something in mind
that motivates the exact options you have selected. Maybe a more specific
example would help.
>
> Paul
>
> --__--__--
>
> Message: 3
> Wrom: GJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSW
> To: "'George Foti (LMC)'" <[email-masked]>,
>         Adam Roach
> <[email-masked]>, [email-masked]
> Subject: RE: [Simple] collection template
> Date: Mon, 28 Oct 2002 13:43:28 -0600
>
> > -----Original Message-----
> > Wrom: ZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULH
> >
> > is it correct
> > to assume that either of the following is correct:
> >
> > a) The RLS will send *individual* SUBSCRIBE to all members of
> > all sub-lists
> > included in the main resource list created by the user when
> > he SUBSCRIBEs to
> > that list.
>
> That would be valid. Of course, the RLS has to know the membership
> of all of the sublists to do so.
>
> > b) The RLS can do procedure (a) for 1 or more sub-lists (in
> > the original
> > list) but can also send a SUBSCRIBE to another RLS for some
> > sub-lists (in
> > the original list). The later RLS can be responsbile for
> > maintaining some
> > lists, and in turn will implement procedure (a).
>
> That would also be valid. The only revision I would make to your
> assertion is: "can do procedure (a) for _zero_ or more sublists..."
>
> Finally, the RLS might have complete information about all of
> the states involved, in which case it would generate *no*
> subscribes to any other node at all.
>
> /a
>
> --__--__--
>
> Message: 4
> Wrom: [email-masked]
> Date: Tue, 29 Oct 2002 08:43:26 +0200
> To: <[email-masked]>
> Subject: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
>
> This is a multi-part message in MIME format.
>
> ------_=_NextPart_001_01C27F16.7BD29B35
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> New draft is now available. Basically draft presents a solution for the =
> requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt.=20
> All comments are welcome.
>
> - Mikko
>
> > -----Original Message-----
> > From: ext [email-masked] [mailto:[email-masked]]
> > Sent: 28 October, 2002 13:27
> > Subject: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> >=20
> >=20
> > A New Internet-Draft is available from the on-line=20
> > Internet-Drafts directories.
> >=20
> >=20
> > Title : SIMPLE PIDF presence capabilities extension
> > Author(s) : M. Lonnfors, K. Kiss
> > Filename : draft-lonnfors-simple-prescaps-ext-00.txt
> > Pages : 14
> > Date : 2002-10-25
> > =09
> > Interoperation of Instant Messaging and Presence systems has been
> > defined in IMPP Working Group.  IMPP WG has come up with baseline
> > interoperable operations and formats for Presence and Instant
> > Messaging systems.  However, these base formats might need
> > standardized extensions in order to enable building rational
> > applications using Presence and Instant Messaging.  This memo
> > proposes an extension to PIDF presence document format to be used in
> > SIMPLE based Presence systems [1] but may also be applied to other
> > protocols as well.
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres
> caps-ext-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to=20
> 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-lonnfors-simple-prescaps-ext-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> 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-lonnfors-simple-prescaps-ext-00.txt".
> =09
> 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.
> =09
> =09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> ------_=_NextPart_001_01C27F16.7BD29B35
> Content-Type: application/octet-stream;
> name="ATT48751.TXT"
> Content-Transfer-Encoding: base64
> Content-Description: ATT48751.TXT
> Content-Disposition: attachment;
> filename="ATT48751.TXT"
>
>
Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt
c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl
eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTEwLTI1MTEyNTI3LkktREBpZXRmLm9yZz4NCg0K
RU5DT0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvbm5mb3JzLXNpbXBs
> ZS1wcmVzY2Fwcy1leHQtMDAudHh0DQo=
>
> ------_=_NextPart_001_01C27F16.7BD29B35
> Content-Type: application/octet-stream;
> name="draft-lonnfors-simple-prescaps-ext-00.URL"
> Content-Transfer-Encoding: base64
> Content-Description: draft-lonnfors-simple-prescaps-ext-00.URL
> Content-Disposition: attachment;
> filename="draft-lonnfors-simple-prescaps-ext-00.URL"
>
>
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
> cy9kcmFmdC1sb25uZm9ycy1zaW1wbGUtcHJlc2NhcHMtZXh0LTAwLnR4dA0K
>
> ------_=_NextPart_001_01C27F16.7BD29B35--
>
> --__--__--
>
> Message: 5
> From: [email-masked]
> Date: Tue, 29 Oct 2002 10:11:49 +0200
> To: <[email-masked]>
> Subject: [Simple] Comment to draft-olson-simple-publish-01.txt
>
> Hi,
>
> Thanks for the new version. Here are some concerns/comments:
>
> - Sections 1.1.5 and 3.4: Facet header
> I am bit confused how this is indented to work. If each PUA always
publishes full state then how is it really possible to use facet header to
indicate to which watcher instances published information is targeted to? As
it is currently defined one PUA could only publish all its information to
one or multiple facets i.e. it is not possible to give some part of that
info so some facets and some other parts to other facet. In current case it
is all or nothing. I would see that better approach would be to include this
kind of information into published content and to authorization rules but
not to publish protocol itself.
> Also it is completely unspecified what should happen if PA does not
support the requested facet. Should it report an error or should there be
some default behavior. Building interoperable system in my mind requires
that these procedures are defined.
>
> - Document does not specify any error handling mechanism for publish. I
think there can be cases where either PA or compositor does not for some
reason understand what PUA has published or that compositor for some reason
cannot add published data into some existing data. Without any error
reporting mechanism is might very hard for PUAs to know what went wrong and
what PUA could do to correct its actions.
>
> - Section 1.1.3 and examples
> Document states that it is possible to associate Class to tuple-ids. This
is also used in examples. As draft-ietf-impp-cpim-pidf-05.txt currently
stands this is not allowed. I don't know if this is going to change in
future versions of PIDF but at a moment associating any semantics to
tuple-ids is forbidden.
>
> Best Regards
> - Mikko
>
> --__--__--
>
> Message: 6
> From: [email-masked]
> Date: Tue, 29 Oct 2002 12:22:34 +0200
> To: <[email-masked]>
> Subject: [Simple] A omment to draft-olson-simple-publish-01
>
> Hi,
>
> Thanks for the much improved -01. One comment though:
>
> Although the draft says that 489 (Bad Event) should be sent in case the
composer doesn't understand the published event state, there is no mention
of Allow-Events used in that case. Allow-Events is mandatory in 489
according to RFC 3265. If it is also mandatory for 489 to a PUBLISH, it
would seem logical that it is also (optionally) used with OPTIONS (for one).
Would then Allow-Events in a 2xx to OPTIONS indicate support for
SUBSCRIBE/NOTIFY, or PUBLISH, or both?
>
> Why not a new pair of headers, which share the event-type (for packages)
namespace with Event/Allow-Events, something like what's described in
http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-00.
txt
>
> AFAIK, we are not running out of space with header names ;)
>
> Cheers,
> Aki
>
>
> --__--__--
>
> Message: 7
> To: IETF-Announce: ;
> CC: [email-masked]
> From: [email-masked]
> Reply-to: [email-masked]
> Date: Tue, 29 Oct 2002 06:17:42 -0500
> Subject: [Simple] I-D ACTION:draft-campbell-simple-im-sessions-00.txt
>
> --NextPart
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Instant Message Sessions in SIMPLE
> Author(s) : B. Campbell, J. Rosenberg
> Filename : draft-campbell-simple-im-sessions-00.txt
> Pages : 11
> Date : 2002-10-28
>
> The SIP MESSAGE method is used to send instant messages, where each
> message is independent of any other message.  This is often called
> pager-mode messaging, due to the fact that this model is similar to
> that of most two-way pager devices.  Another model is called session-
> mode.  In session-mode, the instant messages are part of a media
> session that provides ordering, a security context, and other
> functions.  This media session is established using a SIP INVITE,
> just as an audio or video session would be established.
> This document describes a method of initiating and managing message
> sessions using SIP.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-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-campbell-simple-im-sessions-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-campbell-simple-im-sessions-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.
>
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
> --OtherAccess
> Content-Type: Message/External-body;
> access-type="mail-server";
> server="[email-masked]"
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> ENCODING mime
> FILE /internet-drafts/draft-campbell-simple-im-sessions-00.txt
>
> --OtherAccess
> Content-Type: Message/External-body;
> name="draft-campbell-simple-im-sessions-00.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> --OtherAccess--
>
> --NextPart--
>
>
>
> --__--__--
>
> Message: 8
> To: IETF-Announce: ;
> CC: [email-masked]
> From: [email-masked]
> Reply-to: [email-masked]
> Date: Tue, 29 Oct 2002 06:17:47 -0500
> Subject: [Simple] I-D ACTION:draft-campbell-simple-cpimmsg-sessions-00.txt
>
> --NextPart
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Instant Message Transport Sessions using the CPIM
>                           Message Format
> Author(s) : B. Campbell et al.
> Filename : draft-campbell-simple-cpimmsg-sessions-00.txt
> Pages : 12
> Date : 2002-10-28
>
> Instant Messaging (IM) refers to the transfer of messages between
> users in near real-time.  These messages are usually, but not
> required to be, short.  IMs are often used in a conversational mode,
> that is, the transfer of messages back and forth is fast enough for
> participants to maintain an interactive conversation.  Each message
> can be sent independently using the SIP MESSAGE method, or messages
> can be associated into sessions that are initiated using SIP.  The
> first approach is often referred to as pager-mode messaging, due to
> its similarity to the behavior of two way pager devices.  The second
> approach is often called session-mode messaging, or simply message
> sessions.  This document describes a message session mechanism based
> on the Common Presence and Instant Messaging message format.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-campbell-simple-cpimmsg-sessions-0
0.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-campbell-simple-cpimmsg-sessions-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-campbell-simple-cpimmsg-sessions-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.
>
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
> --OtherAccess
> Content-Type: Message/External-body;
> access-type="mail-server";
> server="[email-masked]"
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> ENCODING mime
> FILE /internet-drafts/draft-campbell-simple-cpimmsg-sessions-00.txt
>
> --OtherAccess
> Content-Type: Message/External-body;
> name="draft-campbell-simple-cpimmsg-sessions-00.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> --OtherAccess--
>
> --NextPart--
>
>
>
> --__--__--
>
> Message: 9
> Date: Tue, 29 Oct 2002 10:05:56 -0500
> From: Paul Kyzivat <[email-masked]>
> To: [email-masked]
> Subject: Re: [Simple] FW: I-D
ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
>
> [email-masked] wrote:
> >
> > Hi,
> >
> > New draft is now available. Basically draft presents a solution for the
requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt.
> > All comments are welcome.
>
> Obviously Mikko and I have been cooperating on this. We were both
interested in the subject. I thought it would be helpful to be clear about
the requirements rather than jumping directly to a proposed solution, so I
posted a requirements draft last week. Since then I have been waiting for
Mikko to submit this in order to have more fodder for discussion.
>
> There is already a work item to produce a SIP-specific profile for PIDF. I
consider these drafts to be a *partial* response to that work item. I
realize there is a desire for some addition generalized status values beyond
open/closed, such as busy. That is a minefield, and we have chosen not to
address it. Instead, we are focusing on some attributes that should be less
controversial because they are drawn from the callerprefs draft, whose basic
concepts have been accepted for a long time. (I am open to discussion about
whether these specific drafts should be expanded to cover the more general
requirement, or whether that should be left separate.)
>
> The assertion of these drafts is that capabilities a UAS can specify when
registering are information that is equally important in a presence
document. I believe Mikko is most concerned with supported media. I also
consider that to be of major importance, but I also believe all the others
are of potential value in a presence document.
>
> The callerprefs draft is still itself in a state of flux. The work here
should remain dependent on the outcome of that work. But I believe it would
be helpful to begin progressing these documents now.
>
> Paul
>
> --__--__--
>
> Message: 10
> From: Robert Sparks <[email-masked]>
> To: [email-masked]
> Date: 29 Oct 2002 10:05:12 -0600
> Subject: [Simple] IETF55 Agenda Requests
>
> Please send me requests for agenda time at the Atlanta SIMPLE meeting.
>
> RjS
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>
> End of simple Digest
>
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple