From owner-um@snowshore.com Mon Feb 10 01:11:38 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1A6BAK27449 for um-outgoing; Mon, 10 Feb 2003 01:11:10 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1A6B9927445 for ; Mon, 10 Feb 2003 01:11:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Subject: [UM] FETCH versus CHANNEL Date: Mon, 10 Feb 2003 01:11:10 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248778@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Alternative to CHANNEL Thread-Index: AcKZH52/SAHjiXucSpC67paMk9SWhw3jg6nw From: "Eric Burger" To: Cc: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h1A6B9927446 Sender: owner-um@snowshore.com Precedence: bulk Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP retrieval (e.g., streaming) of messages. There were a bunch of "yes -- that sounds right" messages. Does anyone object? Do we have consensus to move forward? - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Mon Feb 10 11:44:40 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1AGiXh08964 for um-outgoing; Mon, 10 Feb 2003 11:44:33 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout2.icomverse.com (il-tlv-firewall-main.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1AGiU908960 for ; Mon, 10 Feb 2003 11:44:31 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1AGiIR25819 for ; Mon, 10 Feb 2003 18:44:18 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Feb 2003 18:44:28 +0200 Message-ID: <7D4344E32B34D511A6500002A560C60204D88D60@il-tlv-mail4.comverse.com> From: Erev Ari To: "'um@snowshore.com'" Subject: [UM] Test Message Date: Mon, 10 Feb 2003 18:44:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D123.8DCA60CA" Sender: owner-um@snowshore.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D123.8DCA60CA Content-Type: text/plain; charset="windows-1255" Sent to verify that some problems I have with the list are solved now. ------_=_NextPart_001_01C2D123.8DCA60CA Content-Type: text/html; charset="windows-1255" [UM] Test Message

Sent to verify that some problems I have with the list are solved now.

------_=_NextPart_001_01C2D123.8DCA60CA-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Feb 12 17:53:50 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1CMrSc01416 for um-outgoing; Wed, 12 Feb 2003 17:53:28 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1CMrR901411 for ; Wed, 12 Feb 2003 17:53:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [UM] Agenda for IETF Date: Wed, 12 Feb 2003 17:53:32 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2487BB@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for IETF Thread-Index: AcLS2aYi6vp8MZChR/Orz+9VV3Zq+w== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h1CMrR901412 Sender: owner-um@snowshore.com Precedence: bulk It's that time of year again. Please give us your favorite topics. If you want to write something, remember to get it in by the deadline. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Fri Feb 14 11:56:33 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1EGuM911231 for um-outgoing; Fri, 14 Feb 2003 11:56:22 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1EGuL911227 for ; Fri, 14 Feb 2003 11:56:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: [UM] Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 14 Feb 2003 11:58:13 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2DF7AF@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) Thread-Index: AcLURhjlgkRzQV0bTay8twohB2DTBgABBW9w From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h1EGuL911228 Sender: owner-um@snowshore.com Precedence: bulk NOTE: There are two (2) Internet-Draft Cutoff dates February 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, February 24th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, February 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of February 24th will NOT be accepted. March 3rd: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, March 3rd, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_56.html - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Fri Feb 21 14:34:52 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1LJY2R13911 for um-outgoing; Fri, 21 Feb 2003 14:34:02 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1LJY2913907 for ; Fri, 21 Feb 2003 14:34:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [UM] FW: 56th IETF Meeting - WG & BOF Scheduling - Draft Agenda as of Today Date: Fri, 21 Feb 2003 14:36:08 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2DF7C3@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 56th IETF Meeting - WG & BOF Scheduling - Draft Agenda as of Today Thread-Index: AcLYPZL6qmbfN7NVQeKlAq5rXaFsMABoqcQw From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h1LJY2913908 Sender: owner-um@snowshore.com Precedence: bulk *TENTATIVE* slot. Don't be upset if it changes! -----Original Message----- From: Dinara Suleymanova [mailto:dinaras@ietf.org] Sent: Wednesday, February 19, 2003 12:32 PM To: iesg@ietf.org; wgchairs@ietf.org; bofchairs@ietf.org Subject: 56th IETF Meeting - WG & BOF Scheduling - Draft Agenda as of Today (As of February 19th, 2003) Draft Agenda of the Fifty-sixth IETF March 16-21, 2003 TUESDAY, March 18, 2003 1700-1800 Afternoon Sessions IV APP lemonade License to Enhance Messaging Oriented Network Access for Diverse Endpoints PWG APP webdav WWW Distributed Authoring and Versioning WG INT itrace ICMP Traceback WG OPS grow Global Routing Operations BOF TSV rddp Remote Direct Data Placement WG - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Mon Feb 24 03:36:08 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1O8Zlw21521 for um-outgoing; Mon, 24 Feb 2003 03:35:47 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout2.icomverse.com (il-tlv-firewall-main.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1O8Zi921509 for ; Mon, 24 Feb 2003 03:35:45 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1O8ZWg26903 for ; Mon, 24 Feb 2003 10:35:32 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id <1W08MPS8>; Mon, 24 Feb 2003 10:35:37 +0200 Message-ID: <7D4344E32B34D511A6500002A560C60204D88E4C@il-tlv-mail4.comverse.com> From: Erev Ari To: "'um@snowshore.com'" Subject: [UM] FW: [VPIM] SNAP - next steps Date: Mon, 24 Feb 2003 10:35:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DBDF.944E61F0" Sender: owner-um@snowshore.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DBDF.944E61F0 Content-Type: text/plain; charset="iso-8859-1" Hi, The following message did not appear on the Lemonade list, so I am re-sending it for Noam. Ari -----Original Message----- From: Shapira Noam Sent: Tuesday, February 18, 2003 4:51 PM To: 'snap@lists.neystadt.org'; 'um@snowshore.com'; vpim@lists.neystadt.org Subject: [VPIM] SNAP - next steps Hi, This note is sent to summarize the status of SNAP, as I see it, and to start an open discussion on the list on how to proceed with it. SNAP is now in it's sixth addition. During the last eighteen months, we have worked in the SNAP and VPIM mailing list in order to build what we think is a good notification protocol for mailbox-related/messaging event. During this time, the SNAP was a working draft that incorporated the changes that were agreed by the different participants in the mailing lists. There were some objections but they were resolved in the IETF meetings. Some of the members in the VPIM working group have suggested that we should go on and send the draft to IESG last call. In the last IETF meeting there were a set of substantial pushback against SNAP that led me to conclude that the current draft is not ready for last call. Some of the pushbacks were: - Security model is not sufficient - Subscription/provisioning method - how the servers "get to know each other" - on a subscriber's basis - extensibility of the protocol - The payload format - Etc. Some of these pushbacks were already raised and can be reopened if the forum wishes to do so. Other pushbacks, as I see it, can be pointed to a core problem - the scope of the SNAP. There are two alternatives for SNAP scope: 1. Where the Messaging server and the Notification server are provided by two different service providers (e.g. the email server is held by myemail.com and the notification service by notification.com). Or, 2. Where the Messaging server and the Notification server are provided by the same service provider but not necessarily the same manufacture (e.g. both servers are held by service-provider.com but the email server is from Email-SW-Vendor1 and the notification server is from Notification-SW-Vendor2 The difference is clear. The first option probably needs to handle more issues like: 1. Security / Privacy 2. Provisioning / Subscription 3. User Profile (user identification) Etc. The current draft (maybe with a few small changes) - is suitable for the second scope (common service provider). It is interesting in maintaining an open messaging system - providing the ability to integrate between an email server and a notification server. In this scenario, issues like provisioning, security, persistent connection and other issues can be handled as part of the integration in the service provider site. I think that this draft can be a very good basis to start working on the first option as well. Further, the SNAP current scope deals only with messaging notification - it is not a general purpose notification protocol. It might be the basis for a general purpose protocol - but, after consulting with some of the members of the mailing list - we have decided to limit it to messaging scope (only). The current version has a clear use-case and it was acknowledged in the two mailing lists - but, as I see it, this issue was re-opened. As I see it we have the following two alternatives: 1. Stopping the current SNAP work - and starting (from scratch?) on a more general-purpose notification protocol, (using a different set of basic assumptions and requirements) - for solving Scope 1. 2. Go ahead with the current version - make sure that all disagreements are handled (possibly, creating a better basis for the first option). My opinion is that we should go with the second option - going ahead with the current version. It answers a real need in the field, and it can be closed by the 57th IETF meeting. Taking the route of the first option (Re-start with a different set of requirements) takes us few years back. Solving the larger problem (which is not yet even well-defined) may take pretty long time, and be quite complex (if it to solve all the new requirements). While I do not object for such an effort to take place, I suggest it could be done in stages. Start with the current draft (to solve a "smaller" problem) and extend it, as required, after the new scope/requirements are formulated and agreed upon. Your feedback is welcome, Thanks, Noam ------_=_NextPart_001_01C2DBDF.944E61F0 Content-Type: text/html; charset="iso-8859-1" Message
Hi,
The following message did not appear on the Lemonade list, so I am re-sending it for Noam.
Ari
-----Original Message-----
From: Shapira Noam
Sent: Tuesday, February 18, 2003 4:51 PM
To: 'snap@lists.neystadt.org'; 'um@snowshore.com'; vpim@lists.neystadt.org
Subject: [VPIM] SNAP - next steps

Hi,

This note is sent to summarize the status of SNAP, as I see it, and to start an open discussion on the list on how to proceed with it.

SNAP is now in it's sixth addition. During the last eighteen months, we have worked in the SNAP and VPIM mailing list in order to build what we think is a good notification protocol for mailbox-related/messaging event. During this time, the SNAP was a working draft that incorporated the changes that were agreed by the different participants in the mailing lists. There were some objections but they were resolved in the IETF meetings. Some of the members in the VPIM working group have suggested that we should go on and send the draft to IESG last call.

In the last IETF meeting there were a set of  substantial pushback against SNAP that led me to conclude that the current draft is not ready for last call. Some of the pushbacks were:

- Security model is not sufficient
- Subscription/provisioning method - how the servers "get to know each other" - on a subscriber's basis
- extensibility of the protocol
- The payload format
- Etc.

Some of these pushbacks were already raised and can be reopened if the forum wishes to do so. Other pushbacks, as I see it, can be pointed to a core problem - the scope of the SNAP. There are two alternatives for SNAP scope:

1. Where the Messaging server and the Notification server are provided by two different service providers (e.g. the email server is held by myemail.com and the notification service by notification.com). Or,

2. Where the Messaging server and the Notification server are provided by the same service provider but not necessarily the same manufacture (e.g. both servers are held by service-provider.com  but the email server is from Email-SW-Vendor1 and the notification server is from Notification-SW-Vendor2

The difference is clear. The first option probably needs to handle more issues like:
1. Security / Privacy
2. Provisioning / Subscription
3. User Profile (user identification)
Etc.

The current draft (maybe with a few small changes) - is suitable for the second scope (common service provider). It is interesting in maintaining an open messaging system - providing the ability to integrate between an email server and a notification server. In this scenario, issues like provisioning, security, persistent connection and other issues can be handled as part of the integration in the service provider site. I think that this draft can be a very good basis to start working on the first option as well.

Further, the SNAP current scope deals only with messaging notification - it is not a general purpose notification protocol. It might be the basis for a general purpose protocol - but, after consulting with some of the members of the mailing list - we have decided to limit it to messaging scope (only).

The current version has a clear use-case and it was acknowledged in the two mailing lists - but, as I see it, this issue was re-opened.

As I see it we have the following two alternatives:
1. Stopping the current SNAP work - and starting (from scratch?) on a more general-purpose notification protocol, (using a different set of basic assumptions and requirements) - for solving Scope 1.

2. Go ahead with the current version - make sure that all disagreements are handled (possibly, creating a better basis for the first option).

My opinion is that we should go with the second option - going ahead with the current version. It answers a real need in the field, and it can be closed by the 57th IETF meeting.

Taking the route of the first option (Re-start with a different set of requirements) takes us few years back. Solving the larger problem (which is not yet even well-defined) may take pretty long time, and be quite complex (if it to solve all the new requirements). While I do not object for such an effort to take place, I suggest it could be done in stages. Start with the current draft (to solve a "smaller" problem) and extend it, as required, after the new scope/requirements  are formulated and agreed upon.

Your feedback is welcome,

Thanks,

Noam

------_=_NextPart_001_01C2DBDF.944E61F0-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Feb 25 09:22:43 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1PEMBZ05369 for um-outgoing; Tue, 25 Feb 2003 09:22:11 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout1.icomverse.com (il-tlv-firewall-main.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1PEM9905365 for ; Tue, 25 Feb 2003 09:22:09 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h1PELvd22998 for ; Tue, 25 Feb 2003 16:21:57 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id <1W08M0XZ>; Tue, 25 Feb 2003 16:22:07 +0200 Message-ID: <767720C6032ED511AE8C00508BE3518E0756FBDD@ISMAILWEB> From: Shapira Noam To: "'um@snowshore.com'" Subject: [UM] SNAP - next steps Date: Tue, 25 Feb 2003 16:22:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DCD9.29FDAD60" Sender: owner-um@snowshore.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DCD9.29FDAD60 Content-Type: text/plain; charset="iso-8859-1" Hi, This note is sent to summarize the status of SNAP, as I see it, and to start an open discussion on the list on how to proceed with it. SNAP is now in it's sixth addition. During the last eighteen months, we have worked in the SNAP and VPIM mailing list in order to build what we think is a good notification protocol for mailbox-related/messaging event. During this time, the SNAP was a working draft that incorporated the changes that were agreed by the different participants in the mailing lists. There were some objections but they were resolved in the IETF meetings. Some of the members in the VPIM working group have suggested that we should go on and send the draft to IESG last call. In the last IETF meeting there were a set of substantial pushback against SNAP that led me to conclude that the current draft is not ready for last call. Some of the pushbacks were: - Security model is not sufficient - Subscription/provisioning method - how the servers "get to know each other" - on a subscriber's basis - extensibility of the protocol - The payload format - Etc. Some of these pushbacks were already raised and can be reopened if the forum wishes to do so. Other pushbacks, as I see it, can be pointed to a core problem - the scope of the SNAP. There are two alternatives for SNAP scope: 1. Where the Messaging server and the Notification server are provided by two different service providers (e.g. the email server is held by myemail.com and the notification service by notification.com). Or, 2. Where the Messaging server and the Notification server are provided by the same service provider but not necessarily the same manufacture (e.g. both servers are held by service-provider.com but the email server is from Email-SW-Vendor1 and the notification server is from Notification-SW-Vendor2 The difference is clear. The first option probably needs to handle more issues like: 1. Security / Privacy 2. Provisioning / Subscription 3. User Profile (user identification) Etc. The current draft (maybe with a few small changes) - is suitable for the second scope (common service provider). It is interesting in maintaining an open messaging system - providing the ability to integrate between an email server and a notification server. In this scenario, issues like provisioning, security, persistent connection and other issues can be handled as part of the integration in the service provider site. I think that this draft can be a very good basis to start working on the first option as well. Further, the SNAP current scope deals only with messaging notification - it is not a general purpose notification protocol. It might be the basis for a general purpose protocol - but, after consulting with some of the members of the mailing list - we have decided to limit it to messaging scope (only). The current version has a clear use-case and it was acknowledged in the two mailing lists - but, as I see it, this issue was re-opened. As I see it we have the following two alternatives: 1. Stopping the current SNAP work - and starting (from scratch?) on a more general-purpose notification protocol, (using a different set of basic assumptions and requirements) - for solving Scope 1. 2. Go ahead with the current version - make sure that all disagreements are handled (possibly, creating a better basis for the first option). My opinion is that we should go with the second option - going ahead with the current version. It answers a real need in the field, and it can be closed by the 57th IETF meeting. Taking the route of the first option (Re-start with a different set of requirements) takes us few years back. Solving the larger problem (which is not yet even well-defined) may take pretty long time, and be quite complex (if it to solve all the new requirements). While I do not object for such an effort to take place, I suggest it could be done in stages. Start with the current draft (to solve a "smaller" problem) and extend it, as required, after the new scope/requirements are formulated and agreed upon. Your feedback is welcome, Thanks, Noam ------_=_NextPart_001_01C2DCD9.29FDAD60 Content-Type: text/html; charset="iso-8859-1" Message

Hi,

This note is sent to summarize the status of SNAP, as I see it, and to start an open discussion on the list on how to proceed with it.

SNAP is now in it's sixth addition. During the last eighteen months, we have worked in the SNAP and VPIM mailing list in order to build what we think is a good notification protocol for mailbox-related/messaging event. During this time, the SNAP was a working draft that incorporated the changes that were agreed by the different participants in the mailing lists. There were some objections but they were resolved in the IETF meetings. Some of the members in the VPIM working group have suggested that we should go on and send the draft to IESG last call.

In the last IETF meeting there were a set of  substantial pushback against SNAP that led me to conclude that the current draft is not ready for last call. Some of the pushbacks were:

- Security model is not sufficient
- Subscription/provisioning method - how the servers "get to know each other" - on a subscriber's basis
- extensibility of the protocol
- The payload format
- Etc.

Some of these pushbacks were already raised and can be reopened if the forum wishes to do so. Other pushbacks, as I see it, can be pointed to a core problem - the scope of the SNAP. There are two alternatives for SNAP scope:

1. Where the Messaging server and the Notification server are provided by two different service providers (e.g. the email server is held by myemail.com and the notification service by notification.com). Or,

2. Where the Messaging server and the Notification server are provided by the same service provider but not necessarily the same manufacture (e.g. both servers are held by service-provider.com  but the email server is from Email-SW-Vendor1 and the notification server is from Notification-SW-Vendor2

The difference is clear. The first option probably needs to handle more issues like:
1. Security / Privacy
2. Provisioning / Subscription
3. User Profile (user identification)
Etc.

The current draft (maybe with a few small changes) - is suitable for the second scope (common service provider). It is interesting in maintaining an open messaging system - providing the ability to integrate between an email server and a notification server. In this scenario, issues like provisioning, security, persistent connection and other issues can be handled as part of the integration in the service provider site. I think that this draft can be a very good basis to start working on the first option as well.

Further, the SNAP current scope deals only with messaging notification - it is not a general purpose notification protocol. It might be the basis for a general purpose protocol - but, after consulting with some of the members of the mailing list - we have decided to limit it to messaging scope (only).

The current version has a clear use-case and it was acknowledged in the two mailing lists - but, as I see it, this issue was re-opened.

As I see it we have the following two alternatives:
1. Stopping the current SNAP work - and starting (from scratch?) on a more general-purpose notification protocol, (using a different set of basic assumptions and requirements) - for solving Scope 1.

2. Go ahead with the current version - make sure that all disagreements are handled (possibly, creating a better basis for the first option).

My opinion is that we should go with the second option - going ahead with the current version. It answers a real need in the field, and it can be closed by the 57th IETF meeting.

Taking the route of the first option (Re-start with a different set of requirements) takes us few years back. Solving the larger problem (which is not yet even well-defined) may take pretty long time, and be quite complex (if it to solve all the new requirements). While I do not object for such an effort to take place, I suggest it could be done in stages. Start with the current draft (to solve a "smaller" problem) and extend it, as required, after the new scope/requirements  are formulated and agreed upon.

Your feedback is welcome,

Thanks,

Noam

------_=_NextPart_001_01C2DCD9.29FDAD60-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Feb 25 16:28:34 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1PLSVa12111 for um-outgoing; Tue, 25 Feb 2003 16:28:31 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1PLSU912107 for ; Tue, 25 Feb 2003 16:28:30 -0500 (EST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id NAA18777; Tue, 25 Feb 2003 13:28:07 -0800 Date: Tue, 25 Feb 2003 13:27:47 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Reply-To: Dave Crocker Organization: TribalWise X-Priority: 3 (Normal) Message-ID: <6221153477.20030225132747@dcrocker.net> To: Ted Hardie CC: "IETF LEMONADE (E-mail)" Subject: Re: [UM] RE: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) In-Reply-To: <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sender: owner-um@snowshore.com Precedence: bulk Folks, First of all, I must apologize. Sure enough, I was looking at an older version of the charter, in spite of having tried to avoid that error. The versions that I had seen listed a couple of specifics, in the task list portion, but it was only partial and the overall document seemed to me to leave blind cliffs over which a WG could easily drive. The current version lists specific actions that are clear and concise, except perhaps the one about gatewaying to other services (more on that inline) I gather that the IAB is frankly dictating the current wording of the opening paragraph. I am seriously dismayed to hear that. From an offline exchange, Ned mentions a desire to have the paragraph include something like "link characteristics of concern are those of high latency and low bandwidth, the device characteristics are limited memory and processing power, and the service environments are environments are MMS/WAP." I very heartily concur. In fact it is exactly what I think is missing. Keeping the IAB happy is always important, but I do not believe it should result in a working group charter -- and especially not an opening paragraph -- that is more obscure. However the fact that the remainder of the charter is so specific moves my concern from immediate and strong, to relatively theoretical. Still if there is a way to enhance the opening paragraph, it really would be nice. Something like: Internet mail devices often operate with limited memory or processing power, or with links that have high latency and/or low bandwidth. Existing Internet mail protocols are inefficient in such environments. The Lemonade working group is tasked to provide a set of email enhancements that permit efficient operation in resource-constrained computing and communication environments. The resulting specification(s) will be a seamless enhancement to existing Internet mail. I have not said anything about MMS/WAP because I have no idea what specifics are intended for dealing with them, in spite of your comments. (Hence, for this issue, we are back to my original concern.) More on that, below. Tuesday, February 25, 2003, 11:37:10 AM, you wrote: TH> problem here is that there are a set of services which are being TH> contemplated or deployed in specific environments which are based on TH> IETF protocols but do not interoperate with them, either well or at all. and i certainly agree that we should find a way to avoid that outcome. TH> The list you saw above: link characteristics, device characteristics, TH> or service environments are the differences cited by those operating TH> those service environments as reasons for wanting "profiles" of TH> IETF protocols that meet their needs. and I certainly agree that the current protocols work badly in a number of environments. Hence, unsolicited new mail notification and re-use of server-based content will be spiffy enhancements. I suspect the changes to support streaming content enhancement are really something more general, and will "simply" do a graceful job of moving the specifics of content handling to non-email subsystems, tailored for the particular content. At any rate, yes of course that will be a good enhancement too. >> "A primary goal of this work is to ensure that those profiles and >> enhancements continue to interoperate with the existing Internet >> email protocols in use on the Internet, so that these environments >> and more traditional Internet users have access to a seamless >> service." >> >>No doubt I am misinterpreting this, but it sure sounds as if the goal is >>to create some sort of new email service and try to make sure it can be >>gatewayed to existing Internet email services? TH> Actually, avoiding the need to gateway between services is one of TH> my own goals for this work. I used the term "gateway" very carefully. It is exactly what I get from the current wording. My world model of interconnection is very simple: either the upper-level service is end-to-end and homogeneous, or the interface is between independent, heterogeneous services. Multi-hop handling for the former is relaying; for the latter is is gatewaying (ie, translating). Moving the same content over different *underlying* environments is relaying. >From the current charter, I have no idea what is really intended, concerning MMS/WAP, except that the style of the current language sure makes me lean towards expecting gatewaying. (I'm delighted that you have the intent of avoiding gatewaying, but now perhaps you can appreciate my confusion.) Perhaps the way to clarify this is to focus on what will be true of the end participants, rather than what will not be true at the interface between two parts of the service? Hence, mentioning the interface service because a derivative rather than a focus. (Glad to thrash this privately with you, in an effort to come up with alternate language. Again, I can't offer any yet, because I can't tell what the specific issues and goals are.) All of the above acknowledges that Time Is Passing(c). Still, I've become totally paranoid about charters that are vague. d/ -- Dave Brandenburg InternetWorking t +1.408.246.8253; f +1.408.850.1850 - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Feb 25 17:17:38 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1PMHX712933 for um-outgoing; Tue, 25 Feb 2003 17:17:33 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1PMHV912929; Tue, 25 Feb 2003 17:17:31 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1PMHHYE019067; Tue, 25 Feb 2003 14:17:17 -0800 (PST) Received: from CAMITLOAN6.qualcomm.com (camitloan6.qualcomm.com [129.46.225.112]) by crowley.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1PMHB5O014414; Tue, 25 Feb 2003 14:17:12 -0800 (PST) Message-Id: <5.1.0.14.2.20030225134552.00b0f6d0@mage.qualcomm.com> X-Sender: hardie@mage.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Feb 2003 14:13:55 -0800 To: Dave Crocker From: Ted Hardie Subject: Re: [UM] RE: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Cc: "Eric Burger" , "John C Klensin" , , "Pete Resnick" , , , "IETF LEMONADE (E-mail)" In-Reply-To: <10518983707.20030225125138@brandenburg.com> References: <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-um@snowshore.com Precedence: bulk At 12:51 PM 2/25/2003 -0800, Dave Crocker wrote: >I gather that the IAB is frankly dictating the current wording of the >opening paragraph. I don't know if something I said gave you that impression, but it should not have. I contributed text during a previous round of discussions on the charter (before the last Lemonade BoF); among them was the text you cited. This was not an action of the IAB; it was my personal suggestion. If that was confusing to anyone, I'm sorry that they did not seek clarification at the time. >I am seriously dismayed to hear that. If it were true, it would be a concern. I hope this puts that concern to rest. > From an offline >exchange, Ned mentions a desire to have the paragraph include something >like "link characteristics of concern are those of high latency and low >bandwidth, the device characteristics are limited memory and processing >power, and the service environments are environments are MMS/WAP." I >very heartily concur. In fact it is exactly what I think is missing. I think chartering the working group to look at the problem, rather than over-specifying the details is the right way to go here. If you think just about link characteristics for a moment, I think you'll see that there are situations where non-congestive loss might be more important than the available capacity of the link. This doesn't mean we should change the charter to include the language; it means we should let the working group figure it out. >I used the term "gateway" very carefully. It is exactly what I get from >the current wording. > >My world model of interconnection is very simple: either the upper-level >service is end-to-end and homogeneous, or the interface is between >independent, heterogeneous services. Multi-hop handling for the former >is relaying; for the latter is is gatewaying (ie, translating). Moving >the same content over different *underlying* environments is relaying. I agree that gatewaying implies transformation. I think there is a large rathole in trying to describe "Moving the same content over different *underlying* environments" because there are different ways of understanding what "same content" means. I'd like to see us avoid that rathole entirely. >(Glad to thrash this privately with you, in an effort to come up with >alternate language. Again, I can't offer any yet, because I can't tell >what the specific issues and goals are.) Of the cc list of your message, I'd suggest "um@snowshore.com" as the appropriate place to discuss the matter. regards, Ted Hardie - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Feb 25 19:22:46 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1Q0Mhn14735 for um-outgoing; Tue, 25 Feb 2003 19:22:43 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1Q0Mf914730 for ; Tue, 25 Feb 2003 19:22:42 -0500 (EST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id QAA26177; Tue, 25 Feb 2003 16:21:51 -0800 Date: Tue, 25 Feb 2003 16:19:42 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12231468419.20030225161942@brandenburg.com> To: Ted Hardie CC: "IETF LEMONADE (E-mail)" Subject: Re: [UM] RE: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) In-Reply-To: <5.1.0.14.2.20030225134552.00b0f6d0@mage.qualcomm.com> References: <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <5.1.0.14.2.20030225134552.00b0f6d0@mage.qualcomm.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sender: owner-um@snowshore.com Precedence: bulk Ted, Tuesday, February 25, 2003, 2:13:55 PM, you wrote: >>I gather that the IAB is frankly dictating the current wording of the >>opening paragraph. TH> I don't know if something I said gave you that impression, but Dandy. (I was working from explicit comments from others, but am delighted that such forces have not been at work.) TH> I think chartering the working group to look at the problem, rather TH> than over-specifying the details is the right way to go here. Sometimes it is helpful, or even necessary, to have the charter provide details about the solution choices. But this does not appear to be one of those times, and I am not suggesting otherwise. However, the charter DOES need to make clear what problems are to be solved. And it needs to say them with enough specificity to be meaningful. It simply is not enough to say that we will wander in the space of "different" link characteristics, for example. What kinds of differences? To put it even more simply, the charter should make clear what will be possible AFTER the working group spends its millions of dollars that was not possible -- or not acceptably efficient -- BEFORE. (And, yes, millions -- -- even the most modest IETF standard carries an aggregate cost in that range) TH> If TH> you think just about link characteristics for a moment, I think TH> you'll see that there are situations where non-congestive TH> loss might be more important than the available capacity of TH> the link. This doesn't mean we should change the charter TH> to include the language; it means we should let the working TH> group figure it out. It is fine for a chartered working group to figure out HOW to solve a problem. However it is dangerous for a working group to be left to decide WHAT problem to solve. The first paragraph runs this risk. Of course, the task list, later, is nicely constraining, except for the MMS/WAP reference. TH> I agree that gatewaying implies transformation. I think there TH> is a large rathole in trying to describe "Moving the same content TH> over different *underlying* environments" because there are TH> different ways of understanding what "same content" means. TH> I'd like to see us avoid that rathole entirely. Can't. Sorry. I've just spent a couple of years helping the IMPP group get hopelessly lost because it did not come to grips with this specific question -- in writing -- before doing its specification work. We need to be very, very clear about what interworking we are seeking. I entirely agree that "same content" has a lot of gray area, but a failure to delineate the specifics now will not make things any easier later. It is more likely to make things more difficult. >>(Glad to thrash this privately with you, in an effort to come up with TH> Of the cc list of your message, I'd suggest "um@snowshore.com" The offer was for efficiency, not privacy. glad to make the sausage in public. d/ -- Dave Brandenburg InternetWorking t +1.408.246.8253; f +1.408.850.1850 - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Feb 25 20:16:35 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1Q1GYP15464 for um-outgoing; Tue, 25 Feb 2003 20:16:34 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1Q1GX915460 for ; Tue, 25 Feb 2003 20:16:33 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1Q1GFYE028051; Tue, 25 Feb 2003 17:16:16 -0800 (PST) Received: from [192.168.1.13] (loud.qualcomm.com [129.46.74.134]) by neophyte.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1Q1GBsd013864; Tue, 25 Feb 2003 17:16:11 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <6221153477.20030225132747@dcrocker.net> References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> X-Mailer: Eudora for Mac OS X v6.0a Date: Tue, 25 Feb 2003 17:11:46 -0800 To: Dave Crocker , Ted Hardie From: Randall Gellens Subject: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Cc: "IETF LEMONADE (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 Sender: owner-um@snowshore.com Precedence: bulk At 1:27 PM -0800 2/25/03, Dave Crocker wrote: > "link characteristics of concern are those of high latency and low > bandwidth, Links with high latency and/or low bandwidth (my understanding is that with 3G, bandwidth isn't as much of a concern as latency). > the device characteristics are limited memory and processing > power, Indeed. > and the service environments are environments are MMS/WAP." MMS looks like email with a few extra features, some of which are generally useful (such as forward without download, content transformation, streaming) and some of which are very telephony-specific (such as anonymous messaging and reply-charging). As currently defined, MMS client-server protocols run on WAP; MMS itself looks very much like Internet email, with a few major exceptions, including the use of X-MMS-* headers to carry information and requests that are normally carried in the SMTP envelope or within standard headers. Also, delivery and disposition reports are specified as unstructured text messages. This is likely to cause serious interoperability issues, especially with Internet email. If we had a way to deploy true Internet email that met most of the needs of MMS, it could become an alternative to the WAP method, an alternative that offered far superior interoperability. It would also have those MMS features which are generally useful. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Frequently, people can tell you they've read a book and liked it, but they can't tell you why. We don't want the reader to have to do the hard work of figuring that out. --Duncan Smith, creator of NoveList. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Feb 25 22:29:10 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1Q3T6317159 for um-outgoing; Tue, 25 Feb 2003 22:29:06 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1Q3T5917155 for ; Tue, 25 Feb 2003 22:29:05 -0500 (EST) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1Q3Swo05932 for ; Tue, 25 Feb 2003 22:28:58 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id <1H3QTG8J>; Tue, 25 Feb 2003 21:28:57 -0600 Message-ID: <54E40201497DF142B06B27255953F797037DF9C7@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Randall Gellens , Dave Crocker , Ted Hardie Cc: "IETF LEMONADE (E-mail)" Subject: RE: [UM] Re: WG Review: Enhancements to Internet email to suppor t diverse service environments (lemonade) Date: Tue, 25 Feb 2003 21:28:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-um@snowshore.com Precedence: bulk >> "link characteristics of concern are those of high latency and low >> bandwidth, > >Links with high latency and/or low bandwidth (my understanding is >that with 3G, bandwidth isn't as much of a concern as latency). At current wireless data prices in the US of $10/megabyte, bandwidth concern is a bit different than simple availablity :-) Protocols that enhance the ability of a client to be miserly in it's bandwidth usage are essential. Greg V. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Feb 25 23:01:11 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1Q41A417630 for um-outgoing; Tue, 25 Feb 2003 23:01:10 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1Q418917626 for ; Tue, 25 Feb 2003 23:01:09 -0500 (EST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA02920; Tue, 25 Feb 2003 20:00:40 -0800 Date: Tue, 25 Feb 2003 19:58:22 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1744588244.20030225195822@brandenburg.com> To: Randall Gellens CC: Dave Crocker , Ted Hardie , "IETF LEMONADE (E-mail)" Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) In-Reply-To: References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sender: owner-um@snowshore.com Precedence: bulk Randall, Tuesday, February 25, 2003, 5:11:46 PM, you wrote: >> and the service environments are environments are MMS/WAP." RG> MMS looks like email with a few extra features, some of which are RG> generally useful ... MMS RG> itself looks very much like Internet email, with a few major RG> exceptions, Ok. So... What IS it that Lemonade is suppose to do with MMS? Again, my immediate assumption is to define a formal gateway semantic, but apparently that's not what is planned? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Feb 26 01:07:13 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1Q67AD19130 for um-outgoing; Wed, 26 Feb 2003 01:07:10 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1Q66X919124 for ; Wed, 26 Feb 2003 01:07:08 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1Q66LYE006896; Tue, 25 Feb 2003 22:06:21 -0800 (PST) Received: from [192.168.1.13] (vpn-10-50-16-2.qualcomm.com [10.50.16.2]) by magus.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1Q66B9A025907; Tue, 25 Feb 2003 22:06:15 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <1744588244.20030225195822@brandenburg.com> References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> <1744588244.20030225195822@brandenburg.com> X-Mailer: Eudora for Mac OS X v6.0a Date: Tue, 25 Feb 2003 21:53:42 -0800 To: Dave Crocker , Randall Gellens From: Randall Gellens Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Cc: Dave Crocker , Ted Hardie , "IETF LEMONADE (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 Sender: owner-um@snowshore.com Precedence: bulk At 7:58 PM -0800 2/25/03, Dave Crocker wrote: > Again, my immediate assumption is to define a formal gateway semantic, > but apparently that's not what is planned? I think a gateway is useful, likely essential short-term, but I think more useful long-term would be allowing use of real Internet email. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Implementation is the sincerest form of flattery. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Feb 26 01:33:46 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1Q6Xj319466 for um-outgoing; Wed, 26 Feb 2003 01:33:45 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1Q6Xi919462 for ; Wed, 26 Feb 2003 01:33:44 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1Q6XHIj018464 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 Feb 2003 22:33:18 -0800 (PST) Received: from [192.168.1.13] (vpn-10-50-16-2.qualcomm.com [10.50.16.2]) by neophyte.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1Q6XBsd017013; Tue, 25 Feb 2003 22:33:12 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <01KSVCYM90C2009UB3@mauve.mrochek.com> References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> <01KSVCYM90C2009UB3@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X v6.0a Date: Tue, 25 Feb 2003 22:32:59 -0800 To: ned.freed@mrochek.com, Randall Gellens From: Randall Gellens Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Cc: Dave Crocker , Ted Hardie , "IETF LEMONADE (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 Sender: owner-um@snowshore.com Precedence: bulk At 10:11 PM -0800 2/25/03, ned.freed@mrochek.com wrote: > A completely open-ended charter deliverable to "make > Internet mail into MMS" is simply not acceptable. And I wouldn't want that either. But if we can make Internet mail better in constrained environments, I think it gets better for everyone. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Justify my text? I'm sorry but it has no excuse. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Feb 26 01:52:00 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1Q6pxS19730 for um-outgoing; Wed, 26 Feb 2003 01:51:59 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1Q6pw919726 for ; Wed, 26 Feb 2003 01:51:58 -0500 (EST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id WAA09213; Tue, 25 Feb 2003 22:51:34 -0800 Date: Tue, 25 Feb 2003 22:50:54 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <11454940189.20030225225054@brandenburg.com> To: Randall Gellens CC: Dave Crocker , Ted Hardie , "IETF LEMONADE (E-mail)" Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) In-Reply-To: References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> <1744588244.20030225195822@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sender: owner-um@snowshore.com Precedence: bulk Randall, Tuesday, February 25, 2003, 9:53:42 PM, you wrote: RG> At 7:58 PM -0800 2/25/03, Dave Crocker wrote: >> Again, my immediate assumption is to define a formal gateway semantic, >> but apparently that's not what is planned? RG> I think a gateway is useful, likely essential short-term, but I think RG> more useful long-term would be allowing use of real Internet email. Excellent. This is exactly the type of issue that needs to be surfaced BEFORE starting to do the work. They are two different projects. The might be done in parallel. They might be done in sequence. The first might anticipate the second. But they are entirely different projects. A gateway might benefit from cooperation by the MMS community, but it does not strictly require it. However anything that changes the MMS environment clearly DOES need critical-path cooperation from the MMS community. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Feb 26 10:15:29 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1QFF1600466 for um-outgoing; Wed, 26 Feb 2003 10:15:01 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from oe-im2.bizmailsrvcs.net (oe-im2pub.managedmail.com [206.46.164.53]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1QFF0900434 for ; Wed, 26 Feb 2003 10:15:00 -0500 (EST) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030226151454.HIJM4354.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Wed, 26 Feb 2003 09:14:54 -0600 Received: from RoselinskyM ([68.6.92.160]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030226151454.MDLN14940.oe-ismta2.bizmailsrvcs.net@RoselinskyM>; Wed, 26 Feb 2003 09:14:54 -0600 From: "Milt Roselinsky" To: "Dave Crocker" , "Randall Gellens" Cc: "Ted Hardie" , "IETF LEMONADE \(E-mail\)" Subject: RE: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Date: Wed, 26 Feb 2003 07:15:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1744588244.20030225195822@brandenburg.com> Sender: owner-um@snowshore.com Precedence: bulk MMS has gone a long way to solve some of the problems encountered by the combination of expensive bandwidth and limited capability clients. Within the limitations of MMS' presentation and transcoding capabilities, interoperability with Internet email exists and works fairly well. Others have taken the approach that with minor adaptations, Internet email can be made "mobile network friendly". Examples of this are the messaging deployments in Japan. I would hope that LEMONADE will work on both better interoperability with existing mobile messaging solutions, and required updates to adapt Internet email for mobile applications. Best regards, Milt > -----Original Message----- > From: owner-um@snowshore.com [mailto:owner-um@snowshore.com]On Behalf Of > Dave Crocker > Sent: Tuesday, February 25, 2003 7:58 PM > To: Randall Gellens > Cc: Dave Crocker; Ted Hardie; IETF LEMONADE (E-mail) > Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to > support diverse service environments (lemonade) > > > Randall, > > Tuesday, February 25, 2003, 5:11:46 PM, you wrote: > >> and the service environments are environments are MMS/WAP." > > RG> MMS looks like email with a few extra features, some of which are > RG> generally useful ... MMS > RG> itself looks very much like Internet email, with a few major > RG> exceptions, > > Ok. > > So... > > What IS it that Lemonade is suppose to do with MMS? > > Again, my immediate assumption is to define a formal gateway semantic, > but apparently that's not what is planned? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > - > This list is maintained by Snowshore Networks - http://www.snowshore.com > All comments on this list are the comments of the message originators and > Snowshore is not to be held responsible for any actions or comments found > on this list. The archives for this list can be found at > http://flyingfox.snowshore.com/um_archive/maillist.html > - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Feb 26 11:24:35 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1QGOXo01743 for um-outgoing; Wed, 26 Feb 2003 11:24:33 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1QGOW901739 for ; Wed, 26 Feb 2003 11:24:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: [UM] FW: last call - Draft Agenda - 56th IETF MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 26 Feb 2003 11:26:37 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24881D@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call - Draft Agenda - 56th IETF Thread-Index: AcLdELwVzn2OuEyQQ62Itgxm2c6ELgAoZk5A X-Priority: 1 Importance: high From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h1QGOX901740 Sender: owner-um@snowshore.com Precedence: bulk As promised, it changed: (As of February 25th, 2003) Draft Agenda of the Fifty-sixth IETF March 16-21, 2003 THURSDAY, March 20, 2003 1530-1730 Afternoon Sessions II APP lemonade License to Enhance Messaging Oriented Network Access for Diverse Endpoints PWG - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Feb 26 12:21:17 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1QHLFD02787 for um-outgoing; Wed, 26 Feb 2003 12:21:15 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from oe-im2.bizmailsrvcs.net (oe-im2pub.managedmail.com [206.46.164.53]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1QHLD902783 for ; Wed, 26 Feb 2003 12:21:14 -0500 (EST) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030226172108.HXZW4354.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Wed, 26 Feb 2003 11:21:08 -0600 Received: from RoselinskyM ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030226172104.MRKE14940.oe-ismta2.bizmailsrvcs.net@RoselinskyM>; Wed, 26 Feb 2003 11:21:04 -0600 From: "Milt Roselinsky" To: "Dave Crocker" , "Randall Gellens" Cc: "Ted Hardie" , "IETF LEMONADE \(E-mail\)" Subject: RE: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Date: Wed, 26 Feb 2003 09:21:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <11454940189.20030225225054@brandenburg.com> Sender: owner-um@snowshore.com Precedence: bulk > -----Original Message----- > From: owner-um@snowshore.com [mailto:owner-um@snowshore.com]On Behalf Of > Dave Crocker > Sent: Tuesday, February 25, 2003 10:51 PM > To: Randall Gellens > Cc: Dave Crocker; Ted Hardie; IETF LEMONADE (E-mail) > Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to > support diverse service environments (lemonade) > > > Randall, > > Tuesday, February 25, 2003, 9:53:42 PM, you wrote: > RG> At 7:58 PM -0800 2/25/03, Dave Crocker wrote: > >> Again, my immediate assumption is to define a formal gateway semantic, > >> but apparently that's not what is planned? > > RG> I think a gateway is useful, likely essential short-term, but I think > RG> more useful long-term would be allowing use of real Internet email. > > Excellent. This is exactly the type of issue that needs to be surfaced > BEFORE starting to do the work. > > They are two different projects. > > The might be done in parallel. They might be done in sequence. The first > might anticipate the second. But they are entirely different projects. > > A gateway might benefit from cooperation by the MMS community, but it > does not strictly require it. However anything that changes the MMS > environment clearly DOES need critical-path cooperation from the MMS > community. I agree that these are two projects, and that both would prove valuable. Openwave has been very active in MMS in both 3GPP and OMA. We're eager to participate in the LEMONADE efforts. The need for gateways has already been recognized in the MMS community, and many MMSCs offer this option. There are, of course, some major billing challenges with the Internet email->MMS path that keep many operators from opening up this interface. Milt > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > - > This list is maintained by Snowshore Networks - http://www.snowshore.com > All comments on this list are the comments of the message originators and > Snowshore is not to be held responsible for any actions or comments found > on this list. The archives for this list can be found at > http://flyingfox.snowshore.com/um_archive/maillist.html > - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Feb 27 01:23:23 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1R6NKv14138 for um-outgoing; Thu, 27 Feb 2003 01:23:20 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1R6NI914134 for ; Thu, 27 Feb 2003 01:23:18 -0500 (EST) Received: from msfc03-dai-tx-38-252.rasserver.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id WAA01925; Wed, 26 Feb 2003 22:22:50 -0800 Date: Wed, 26 Feb 2003 21:47:38 -0600 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <638399057.20030226214738@brandenburg.com> To: ned.freed@mrochek.com CC: "IETF LEMONADE (E-mail)" Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) In-Reply-To: <01KSVK22FX2C007FVT@mauve.mrochek.com> References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> <1744588244.20030225195822@brandenburg.com> <11454940189.20030225225054@brandenburg.com> <01KSVK22FX2C007FVT@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-um@snowshore.com Precedence: bulk Folks, Wednesday, February 26, 2003, 1:37:07 AM, you wrote: >> The might be done in parallel. They might be done in sequence. The first >> might anticipate the second. But they are entirely different projects. nfmc> And both projects are already on the list of WG deliverables. We have nfmc> deliverables intended to make Internet mail more usable in these nfmc> sorts of environments and a deliverable intended to make Internet mail nfmc> work better with MMS. nfmc> I really don't see what the issue is here. The last day's worth of email has provided quite a bit of essential explanation and clarification, which I believe the current draft charter is lacking. In terms of basic goals, the recent discussion to describe two different deliverable: 1. Enhancements to Internet mail for better operation with resource-constrained devices and with channels that are high latency and/or low bandwidth 2. Specification of a gateway between existing Internet mail and other email services operating in such constrained environments. I'm not quibbling about opening paragraph word-smithing, here. I see this as a very basic and entirely essential distinction that needs to be made explicit, so that participants can be crystal clear about the two different activities of the working group. The mere fact that it has taken this much work to get folks to articulate the two different foci is reason enough to make sure the charter is clear about the distinction. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Feb 27 01:56:53 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1R6uqD14572 for um-outgoing; Thu, 27 Feb 2003 01:56:52 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1R6un914568 for ; Thu, 27 Feb 2003 01:56:50 -0500 (EST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KSWQCI5BUO002DEU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for um@snowshore.com; Wed, 26 Feb 2003 22:56:44 -0800 (PST) Date: Wed, 26 Feb 2003 22:54:30 -0800 (PST) From: NED+um@mauve.mrochek.com Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) In-reply-to: "Your message dated Wed, 26 Feb 2003 21:47:38 -0600" <638399057.20030226214738@brandenburg.com> To: Dave Crocker Cc: ned.freed@mrochek.com, "IETF LEMONADE (E-mail)" Message-id: <01KSWSOTZRMS002DEU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> <1744588244.20030225195822@brandenburg.com> <11454940189.20030225225054@brandenburg.com> <01KSVK22FX2C007FVT@mauve.mrochek.com> <638399057.20030226214738@brandenburg.com> Sender: owner-um@snowshore.com Precedence: bulk > Folks, > Wednesday, February 26, 2003, 1:37:07 AM, you wrote: > >> The might be done in parallel. They might be done in sequence. The first > >> might anticipate the second. But they are entirely different projects. > nfmc> And both projects are already on the list of WG deliverables. We have > nfmc> deliverables intended to make Internet mail more usable in these > nfmc> sorts of environments and a deliverable intended to make Internet mail > nfmc> work better with MMS. > nfmc> I really don't see what the issue is here. > The last day's worth of email has provided quite a bit of essential > explanation and clarification, which I believe the current draft > charter is lacking. > In terms of basic goals, the recent discussion to describe two > different deliverable: > 1. Enhancements to Internet mail for better operation with > resource-constrained devices and with channels that are high latency > and/or low bandwidth Deliverables 1, 2, and 3. > 2. Specification of a gateway between existing Internet mail and > other email services operating in such constrained environments. Deliverable 5. > I'm not quibbling about opening paragraph word-smithing, here. > I see this as a very basic and entirely essential distinction that > needs to be made explicit, so that participants can be crystal clear > about the two different activities of the working group. They are completely separate deliverables already. I'm at a loss as to how they could possibly be made more separate. > The mere fact that it has taken this much work to get folks to > articulate the two different foci is reason enough to make sure the > charter is clear about the distinction. I'm still not seeing the lack of clarity here. Ned - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Feb 27 13:22:21 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1RIM0n28513 for um-outgoing; Thu, 27 Feb 2003 13:22:00 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1RILv928509 for ; Thu, 27 Feb 2003 13:21:58 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1RILfYE023026; Thu, 27 Feb 2003 10:21:43 -0800 (PST) Received: from CAMITLOAN6.qualcomm.com (camitloan6.qualcomm.com [129.46.225.112]) by neophyte.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1RILcsd007053; Thu, 27 Feb 2003 10:21:39 -0800 (PST) Message-Id: <5.1.0.14.2.20030227100404.03ce3278@mage.qualcomm.com> X-Sender: hardie@mage.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Feb 2003 10:14:12 -0800 To: NED+um@mauve.mrochek.com, Dave Crocker From: Ted Hardie Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Cc: ned.freed@mrochek.com, "IETF LEMONADE (E-mail)" In-Reply-To: <01KSWSOTZRMS002DEU@mauve.mrochek.com> References: <"Your message dated Wed, 26 Feb 2003 21:47:38 -0600" <638399057.20030226214738@brandenburg.com> <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> <1744588244.20030225195822@brandenburg.com> <11454940189.20030225225054@brandenburg.com> <01KSVK22FX2C007FVT@mauve.mrochek.com> <638399057.20030226214738@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-um@snowshore.com Precedence: bulk Dave, I've followed up some of Ned's comments inline below. At 10:54 PM 2/26/2003 -0800, NED+um@mauve.mrochek.com wrote: > > 1. Enhancements to Internet mail for better operation with > > resource-constrained devices and with channels that are high latency > > and/or low bandwidth > >Deliverables 1, 2, and 3. > > > 2. Specification of a gateway between existing Internet mail and > > other email services operating in such constrained environments. > >Deliverable 5. > > > I'm not quibbling about opening paragraph word-smithing, here. > > > I see this as a very basic and entirely essential distinction that > > needs to be made explicit, so that participants can be crystal clear > > about the two different activities of the working group. Maybe I misunderstood you, but I thought you believed that the deliverables were clear and constrained in the new version. With Ned's pointer to how the deliverables map to the two activities of the group we've been discussing, I think we're back to the question of the opening paragraph word smithing. There's really only so much that can be done there; we shouldn't try to include all the deliverables in it any more than we should do the work of the working group while drafting the charter. About the only thing we could do more is have an explicit forward pointer to the deliverables. Given the strength of the implicit forward pointer, that does not really seem needed to me. I think we all share your desire to ensure that this group stays focused, and we all understand the role the charter plays in helping the chairs do that work. I hope you share our view that the whole charter plays that role, not just the working group description. regards, Ted Hardie - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Fri Feb 28 14:44:50 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1SJiYd24243 for um-outgoing; Fri, 28 Feb 2003 14:44:34 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1SJiX924235 for ; Fri, 28 Feb 2003 14:44:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [UM] RE: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Date: Fri, 28 Feb 2003 14:46:38 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248838@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [UM] RE: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) Thread-Index: AcLdEA7EqEx/inPFQ6aHG0i8FTXPdQB8G1/Q From: "Eric Burger" To: "Dave Crocker" Cc: , , "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h1SJiX924236 Sender: owner-um@snowshore.com Precedence: bulk It is unquestionably true that the motivation for the work group is to enable "lesser" access methods to work with Internet e-mail. One may reasonably argue that optimization for a particular access method is not the work of the IETF. That is, we usually say, "Fix the lesser access method." However, I would offer two reasons to go ahead with the work. The first is volume. If one believes the projections for wireless data access, very shortly there will be orders of magnitude more "lesser"-connected devices than traditional Internet devices. Said differently, it will be the traditional devices that will be in the minority. By sheer economics, this may result in the marginalization of IETF protocols in favor of the more ubiquitous (and closed-process developed), explicitly-wireless protocols. The second reason is that almost all of the extensions and adaptations proposed in the charter improves Internet mail in general. Here are some examples. o Remote submission: In the wireless environment, nobody wants to download a 40KB message to forward it. Likewise, when I'm dialed up on my conventional PC, I don't want to download a 1MB message to forward it, either. o Streaming: In the wireless environment, the latency associated with fully downloading a voice message before playing it is unacceptable. In the conventional environment, the latency and storage associated with fully downloading a video object is unacceptable, too. o Multimodal access: In the wireless environment, we get a small GUI and a TUI. In the conventional environment, we will shortly be seeing integrated GUI, SUI (Speech User Interface), and Ink (Stylus User Interface) clients. Dave hits upon an important point. The goal of the work group is not to create a set of protocol extensions for some odd combination of proprietary and "walled garden" devices and networks. The goal is to improve the Internet e-mail infrastructure in general, with the immediate goal in incorporating devices and networks of lesser capability. We have an example of such an activity in the U.S. The ADA law had the (intended) consequence of making access easier for EVERYONE, as well as those that are disabled. In the same manner, the idea of lemonade is to improve e-mail for everyone. Logical conclusion of this concept is that lemonade must not break e-mail for anyone. Examples of what we don't want to do are creating a non-interoperable profile of SMTP or increasing the complexity of IMAP. > -----Original Message----- > From: Dave Crocker [mailto:dcrocker@brandenburg.com] > Sent: Tuesday, February 25, 2003 3:52 PM > To: Ted Hardie > Cc: Eric Burger; John C Klensin; ned.freed@mrochek.com; Pete Resnick; > ietf@ietf.org; iesg@ietf.org; UM list > Subject: Re: [UM] RE: WG Review: Enhancements to Internet email to > support diverse service environments (lemonade) > > > Folks, > > First of all, I must apologize. Sure enough, I was looking at an older > version of the charter, in spite of having tried to avoid that error. > The versions that I had seen listed a couple of specifics, in the task > list portion, but it was only partial and the overall > document seemed to > me to leave blind cliffs over which a WG could easily drive. > > The current version lists specific actions that are clear and concise, > except perhaps the one about gatewaying to other services > (more on that > inline) > > I gather that the IAB is frankly dictating the current wording of the > opening paragraph. I am seriously dismayed to hear that. From > an offline > exchange, Ned mentions a desire to have the paragraph include > something > like "link characteristics of concern are those of high > latency and low > bandwidth, the device characteristics are limited memory and > processing > power, and the service environments are environments are MMS/WAP." I > very heartily concur. In fact it is exactly what I think is missing. > > Keeping the IAB happy is always important, but I do not believe it > should result in a working group charter -- and especially not an > opening paragraph -- that is more obscure. However the fact that the > remainder of the charter is so specific moves my concern from > immediate > and strong, to relatively theoretical. > > Still if there is a way to enhance the opening paragraph, it really > would be nice. Something like: > > Internet mail devices often operate with limited memory or > processing power, or with links that have high latency > and/or low > bandwidth. Existing Internet mail protocols are inefficient in > such environments. The Lemonade working group is tasked > to provide > a set of email enhancements that permit efficient operation in > resource-constrained computing and communication > environments. The > resulting specification(s) will be a seamless enhancement to > existing Internet mail. > > I have not said anything about MMS/WAP because I have no idea what > specifics are intended for dealing with them, in spite of > your comments. > (Hence, for this issue, we are back to my original concern.) More on > that, below. > > > Tuesday, February 25, 2003, 11:37:10 AM, you wrote: > TH> problem here is that there are a set of services which are being > TH> contemplated or deployed in specific environments which > are based on > TH> IETF protocols but do not interoperate with them, either > well or at all. > > and i certainly agree that we should find a way to avoid that outcome. > > > TH> The list you saw above: link characteristics, device > characteristics, > TH> or service environments are the differences cited by > those operating > TH> those service environments as reasons for wanting "profiles" of > TH> IETF protocols that meet their needs. > > and I certainly agree that the current protocols work badly > in a number > of environments. > > Hence, unsolicited new mail notification and re-use of server-based > content will be spiffy enhancements. > > I suspect the changes to support streaming content enhancement are > really something more general, and will "simply" do a graceful job of > moving the specifics of content handling to non-email subsystems, > tailored for the particular content. At any rate, yes of course that > will be a good enhancement too. > > > >> "A primary goal of this work is to ensure that those > profiles and > >> enhancements continue to interoperate with the > existing Internet > >> email protocols in use on the Internet, so that these > environments > >> and more traditional Internet users have access to a seamless > >> service." > >> > >>No doubt I am misinterpreting this, but it sure sounds as > if the goal is > >>to create some sort of new email service and try to make > sure it can be > >>gatewayed to existing Internet email services? > > TH> Actually, avoiding the need to gateway between services is one of > TH> my own goals for this work. > > I used the term "gateway" very carefully. It is exactly what > I get from > the current wording. > > My world model of interconnection is very simple: either the > upper-level > service is end-to-end and homogeneous, or the interface is between > independent, heterogeneous services. Multi-hop handling for the former > is relaying; for the latter is is gatewaying (ie, translating). Moving > the same content over different *underlying* environments is relaying. > > From the current charter, I have no idea what is really intended, > concerning MMS/WAP, except that the style of the current language sure > makes me lean towards expecting gatewaying. (I'm delighted > that you have > the intent of avoiding gatewaying, but now perhaps you can > appreciate my > confusion.) > > Perhaps the way to clarify this is to focus on what will be > true of the > end participants, rather than what will not be true at the interface > between two parts of the service? Hence, mentioning the interface > service because a derivative rather than a focus. > > (Glad to thrash this privately with you, in an effort to come up with > alternate language. Again, I can't offer any yet, because I can't tell > what the specific issues and goals are.) > > All of the above acknowledges that Time Is Passing(c). Still, I've > become totally paranoid about charters that are vague. > > d/ > -- > Dave > Brandenburg InternetWorking > t +1.408.246.8253; f +1.408.850.1850 > > - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Fri Feb 28 14:44:50 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h1SJiap24244 for um-outgoing; Fri, 28 Feb 2003 14:44:36 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h1SJiX924237 for ; Fri, 28 Feb 2003 14:44:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [UM] SNAP - next steps Date: Fri, 28 Feb 2003 14:46:38 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24883A@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [UM] SNAP - next steps Thread-Index: AcLc2cejgSmXwf7UQPuFqO49FghodQCKtnMg From: "Eric Burger" To: "Shapira Noam" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h1SJiX924238 Sender: owner-um@snowshore.com Precedence: bulk Here is the key issue that I am stuck on: Original Message From: Shapira Noam [mailto:Shapira_Noam@icomverse.com] Sent: Tuesday, February 25, 2003 9:22 AM [snip] > 2. Where the Messaging server and the Notification server are provided > by the same service provider but not necessarily the same manufacture > (e.g. both servers are held by service-provider.com but the email server > is from Email-SW-Vendor1 and the notification server is from Notification-SW-Vendor2 > > The difference is clear. The first option probably needs to handle > more issues like: > 1. Security / Privacy > 2. Provisioning / Subscription > 3. User Profile (user identification) > Etc. I would offer that situation 2 is explicitly not the kind of protocol the IETF publishes. The issues listed for situation 1 ARE the issues listed that a real Internet solution needs to address. I would liken this situation to the one raised by the Security Considerations draft from the IAB . From the draft: Internet protocol designers cannot safely assume that their protocols will be deployed in such an environment [a walled garden], for three reasons. First, protocols which were originally designed to be deployed in closed environments often are later deployed on the Internet, thus creating serious vulnerabilities. Second, networks which appear to be topologically disconnected may not be. One reason may be that the network has been reconfigured to allow access by the outside world. Moreover, firewalls are increasingly passing generic application layer protocols such as [SOAP] or [HTTP]. Network protocols which are based on these generic protocols cannot in general assume that a firewall will protect them. Although the second paragraph is speaking specifically about firewalls, I would offer the issues are identical for notification protocols. Protocol proposals, to be an IETF protocol, must address INTERNET requirements. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html