headers
Pete Resnick | 3 Dec 2001 19:11

Agenda


What are we talking about other than ANNOTATE and ACL?

pr
--

-- 
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 2 comments |
headers
Shapira, Noam | 3 Dec 2001 19:39

RE: Agenda


Hi,

I would be happy if I could get the opportunity to present the new version
of SNAP (Simple Notification and Alarm Protocol) - discuss some of the
decisions taken in the new draft (some of which where raised in this mailing
list and in other mailing list).

The new draft is available in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt.

Noam

> -----Original Message-----
> From: Pete Resnick [mailto:presnick <at> qualcomm.com]
> Sent: Monday, December 03, 2001 8:12 PM
> To: ietf-imapext <at> imc.org
> Subject: Agenda
> 
> 
> 
> What are we talking about other than ANNOTATE and ACL?
> 
> pr
> -- 
> Pete Resnick <mailto:presnick <at> qualcomm.com>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: 
> (858)651-1102
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pete Resnick | 3 Dec 2001 19:49

RE: Agenda


On 12/3/01 at 8:39 PM +0200, you wrote:

>I would be happy if I could get the opportunity to present the new version
>of SNAP (Simple Notification and Alarm Protocol) - discuss some of the
>decisions taken in the new draft (some of which where raised in this mailing
>list and in other mailing list).

There won't be presentations in the WG session. I'd be happy to give 
you time on the agenda if you write up and send out to the WG list 
(in the next day or so) the decisions taken in the new draft that you 
wish to discuss. We don't need to waste the time having you present 
this in the WG session itself. Send a message, let people comment on 
the list, and those items that don't get satisfactory review can be 
discussed at the WG meeting.

pr
--

-- 
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 3 Dec 2001 19:55

Re: Agenda


--On Monday, December 3, 2001 12:11 PM -0600 Pete Resnick 
<presnick <at> qualcomm.com> wrote:

> What are we talking about other than ANNOTATE and ACL?

Conditional store - since ANNOTATE references that. Also we should discuss 
the issue of i18n for SORT/THREAD (which was a requirement from the last 
meeting). There is an i18n for internet protocols boff earlier in the week 
which I think will be relevant to this.

--

-- 
Cyrus Daboo
Permalink | Reply | 1 comment |
headers
Alexey Melnikov | 4 Dec 2001 06:13

Re: Agenda


Cyrus Daboo wrote:

> --On Monday, December 3, 2001 12:11 PM -0600 Pete Resnick
> <presnick <at> qualcomm.com> wrote:
>
> > What are we talking about other than ANNOTATE and ACL?
>
> Conditional store - since ANNOTATE references that. Also we should discuss
> the issue of i18n for SORT/THREAD (which was a requirement from the last
> meeting). There is an i18n for internet protocols boff earlier in the week
> which I think will be relevant to this.

I tend to agree with Cyrus.

We can also discuss LISTEXT if there is enough interest (Barry, are you coming
to Salt Lake?)

On a related note, what happend to WINDOW?

Alexey
Permalink | Reply | 0 comments |
headers
Barry Leiba | 4 Dec 2001 06:37
Picon
Favicon

Re: Agenda


> We can also discuss LISTEXT if there is enough interest (Barry, are you
> coming to Salt Lake?)

I'm not, no -- no travel money.  If you discuss it, though, send me notes
and I'll make adjustments to the draft, and we can continue discussion on
the mailing list -- 's been pretty quiet of late.

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba <at> watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
Permalink | Reply | 2 comments |
headers
Shapira, Noam | 4 Dec 2001 18:38

SNAP progress and request for comment


Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shapira, Noam | 5 Dec 2001 07:13

SNAP progress and request for comment


Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shapira, Noam | 5 Dec 2001 07:39

SNAP progress and request for comment


Hi all,

As you know, a new SNAP draft has been submitted to (can be found in
http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).

As one can recall, the SNAP describes a notification protocol between a
Messaging Server (e.g. Email Server) and a Notification server (as specified
in the draft).

I would like to share some of the changes / decisions made and ask for
comment on them:

1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
putting it in the SNAP mailing list). There where 3 alternatives:
	- HTTP
	- BEEP
	- No binding (and leaving the decision to the implementers).
    Comments?

2. Choose 2822 like as the format of the SNAP payload. Again, there where a
few alternatives:
	- 2822 Like,
	- XML
	- In the HTTP query string (in the format of "attribute = value&)
    2822 like format was chosen as it is more "friendly" to email servers.
XML has a great deal of supporters as well so it was hard to decide. I would
be happy to get comments.

3. Make sure that the SNAP is compatible with 2822.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Newman | 10 Dec 2001 00:16

Re: SNAP progress and request for comment


--On Wednesday, December 5, 2001 8:39 +0200 "Shapira, Noam" 
<Shapira_Noam <at> icomverse.com> wrote:
> 1. Bind the SNAP to HTTP. This was a very big issue that we closed (after
> putting it in the SNAP mailing list). There where 3 alternatives:
> 	- HTTP
> 	- BEEP
> 	- No binding (and leaving the decision to the implementers).
>     Comments?

I strongly prefer BEEP because this is the sort of thing BEEP was designed 
for.  I am strongly opposed to an HTTP-only option, because HTTP is two or 
three times the complexity of BEEP and provides less functionality when 
abused as a protocol framework.  In particular, HTTP has an inflexible 
security model, complex and spotty support for persistant connections, and 
complex proxy semantics.  You'll have to write a lot of text to justify the 
abuse of HTTP and there's a good chance the IESG will reject it, especially 
given the experience with IPP.  BEEP would be a slam-dunk.

> 2. Choose 2822 like as the format of the SNAP payload. Again, there where
> a few alternatives:
> 	- 2822 Like,
> 	- XML
> 	- In the HTTP query string (in the format of "attribute = value&)
>     2822 like format was chosen as it is more "friendly" to email servers.
> XML has a great deal of supporters as well so it was hard to decide. I
> would be happy to get comments.

I'd lean slightly towards XML, since I think all email servers will 
eventually end up with an XML parser for one reason or another, but there's
(Continue reading)

Permalink | Reply | 0 comments |

Gmane