headers
Vaudreuil, Greg M (Greg | 2 May 2002 03:44
Picon
Favicon

FW: I-D ACTION:draft-vaudreuil-futuredelivery-00.txt

FYI

Greg V.
Picon Favicon
From: FYI Greg V. <Internet-Drafts <at> ietf.org>
Subject: I-D ACTION:draft-vaudreuil-futuredelivery-00.txt
Date: 2002-05-01 11:25:45 GMT
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: SMTP Submission Service Extension for Future
Delivery
	Author(s)	: G. White, G. Vaudreuil
	Filename	: draft-vaudreuil-futuredelivery-00.txt
	Pages		: 12
	Date		: 30-Apr-02
	
This memo defines an extension to the SMTP submission protocol for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 2 May 2002 04:00

Re: FW: I-D ACTION:draft-vaudreuil-futuredelivery-00.txt

On 5/1/02 at 7:44 PM -0600, Greg M (Greg) Vaudreuil wrote:

>This memo defines an extension to the SMTP submission protocol for 
>client indication of a future-delivery time.

I have no problem with the SMTP submission extension, but I really 
think section 4 is a bad idea. If you've got no IMAP store and you 
just want something queued for a particular time, it would be fine to 
use this SMTP extension. However, if there is going to be an IMAP 
store where you can delete the message, I think this is just the 
wrong way to do it. There should be a command in IMAP to submit a 
message to SMTP (e.g., what I've been talking about adapting the 
CHANNEL command to do), and that mechanism should have a future 
delivery specifier. If this wants to be an IMAP mechanism, make it an 
IMAP mechanism. If you still need a separate SMTP mechanism, keep it 
separate.

pr
--

-- 
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
----------------------------------------------------------
This message was sent to you, since you are subscribed to
vpim <at> lists.neystadt.org. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo
Permalink | Reply | 0 comments |
headers
Glenn Parsons | 4 May 2002 21:25

WG Last Call Completed on Calling Line ID

Folks,

We have finished WG last call on the Calling Line Identification for Voice Mail Messages document (it ended several weeks ago :-) .  No comments were received, so the current proposed document remains:

http://www.ietf.org/internet-drafts/draft-ema-vpim-clid-04.txt

I have asked our ADs to review these so that we can send them for an IETF last call.

The intent is for this to become an Proposed Standard RFC.

Cheers,
Glenn.


Permalink | Reply | 0 comments |
headers
Shapira, Noam | 14 May 2002 10:01

SNAP - last changes

Hi all,

The SNAP protocol draft is in it's final stages. The last draft has been sent on February and the changes were presented by my associate (Eli Jacobi) in the last IETF meeting (IETF #53). The changes can be found in the appendix to the draft (that can be found in <http://www.ietf.org/internet-drafts/draft-shapira-snap-03.txt>).

There are currently two main open issues:

1. The issue of attachment name and number:
* Should it be in SNAP? Currently, in our implementation - we are not using it - but as far as I can see it - it might be needed later on.

* If it should be in SNAP - should we add to the draft implementation instruction to the email server developer or should we keep it open (for implementation decision)?

* If we provide implementation instruction - should it be according to content-disposition header (as I suggested before) or perhaps using the body-structure.

I would be thankful for opinions on these options.

2. The issue of security:
In the last IETF meeting the issue of security was raised again:
* The protocol should not discuss tunneling through firewalls
* The protocol should not use the standard port of HTTP - but rather register a new one.
Currently the draft talks about the different security consideration that the SNAP implementer should take in consideration. It does not discuss how to overcome these problems - rather leaves it to be an implementer decision.

As far as I can see it - in the next draft I am going to add a registration for a new port. Does any one have any objections?

After closing the two open issues -I would like to send the draft for last-call. If there are other open issues as far as you can see it - please let me know.

Thanks

Noam Shapira
Notification Group Leader
Corporate Components
InCom, R&D
Tel: 972-3-766-3605
Mobile: 972-58-543605


Permalink | Reply | 0 comments |
headers
Shapira, Noam | 15 May 2002 12:59

RE: [SNAP] SNAP - last changes

Hi Sergio,

See inside

> -----Original Message-----
> From: Sergio Freire [mailto:est-s-freire <at> ptinovacao.pt]
> Sent: Tuesday, May 14, 2002 11:55 AM
> To: Shapira, Noam
> Cc: snap <at> lists.neystadt.org; vpim <at> lists.neystadt.org; Mario Moreira
> Subject: Re: [SNAP] SNAP - last changes
>
>
> Hi Shaphira, hi all,
> About the issues that you mention,
>
> 1. In fact these two fields in most cases won't be needed
> although they
> might be of some use..
>
> 2. About the port used by SNAP, well in my opinion it shouldn't be
> specificied by the draft. It should be a
> developer/implementation issue.
> The Notification Server is suposed to run under a restricted
> LAN, so why
> is the port number an issue ?
> Asssigning a specific port adds some contraint to the draft.
> SNAP should
> care with the protocol itself, the syntax and not with the
> port because
> its suposed to run anywhere. For example, you might see it
> running it on
> HTTP port 80 in most of the cases.
I tend to disagree with you - One of the comments that I got in the last IETF meeting was that we should not use the standard (80) port for the protocol. This is a security hazard and will not allow firewalls to monitor the incoming SNAP requests.

>
> Another remarks:
> a) Message-Context predefined values aren't of too much
> sense,  if for
> VOICE and FAX you get a Message-Context of "voice-message" and
> "fax-message", why shouldn't likely get a "email-message" for
> the type
> EMAIL ?
The different values are taken from VPIM working group draft - draft-ietf-vpim-hint-07 - and I tried to stay with this standard.

>
> b) In Counters-Group, section 3.6.1, 3.6.2 and 3.6.3
> shouldn't they be
> "Total-Voice-Message", "Total-New-Voice-Message" and
> "Total-New-Urgent-Voice-Message" ? Since all other counter fields are
> like "Total-xxx-Message", why is this one "Total-xxx-Messages" ?
>
I agree - it will be fixed.

> c) Shouldn't there exist counters for the total of messages,
> including
> all types ? Something like "Total-Message", "Total-New-Message" and
> "Total-New-Urgent-Message" ?
>
I think this information can be derived from the other counters and therefore not needed. Why do you think it is needed?

> d) Shouldn't there be a Request-Type specifying rules for
> notification
> delivery ? There could be a Request-Type like "New-Rule"
> which had all
> fields necessary for the Nonfiction Server to process and
> know if it has
> to deliver it, how and when ? I can give a contribution on
> this matter...
This protocol is between an email server and a notification server. What you are saying is that the rule will be sent from the email server - which I think is wrong architecturally. If you are talking about provisioning of this service - this issue has been raised before and we (in the mailing list) decided not to tackle the problem in the draft. I think it is a good idea to have complimentary RFC that will talk about the provisioning of this service.

>
> Regards,
>
> Sergio Freire
> Services and Mobile Networks
> PT Inovação
> Portugal Telecom
>
> Shapira, Noam wrote:
>
> > Hi all,
> >
> > The SNAP protocol draft is in it's final stages. The last draft has
> > been sent on February and the changes were presented by my
> associate
> > (Eli Jacobi) in the last IETF meeting (IETF #53). The
> changes can be
> > found in the appendix to the draft (that can be found in_
> >
> __<__http://www.ietf.org/internet-drafts/draft-shapira-snap-03
> .txt__>_).
> >
> > There are currently two main open issues:
> >
> > 1. The issue of attachment name and number:
> > * Should it be in SNAP? Currently, in our implementation -
> we are not
> > using it - but as far as I can see it - it might be needed later on.
> >
> > * If it should be in SNAP - should we add to the draft
> implementation
> > instruction to the email server developer or should we keep it open
> > (for implementation decision)?
> >
> > * If we provide implementation instruction - should it be
> according to
> > content-disposition header (as I suggested before) or perhaps using
> > the body-structure.
> >
> > I would be thankful for opinions on these options.
> >
> > 2. The issue of security:
> > In the last IETF meeting the issue of security was raised again:
> > * The protocol should not discuss tunneling through firewalls
> > * The protocol should not use the standard port of HTTP - but rather
> > register a new one.
> > Currently the draft talks about the different security
> consideration
> > that the SNAP implementer should take in consideration. It does not
> > discuss how to overcome these problems - rather leaves it to be an
> > implementer decision.
> >
> > As far as I can see it - in the next draft I am going to add a
> > registration for a new port. Does any one have any objections?
> >
> > After closing the two open issues -I would like to send the
> draft for
> > last-call. If there are other open issues as far as you can
> see it -
> > please let me know.
> >
> > Thanks
> >
> > *Noam Shapira*
> > *Notification Group Leader*
> > *Corporate Components*
> > *InCom, R&D*
> > *Tel: 972-3-766-3605*
> > *Mobile: 972-58-543605*
> >
> >
>
>
>

Permalink | Reply | 0 comments |
headers
NED+vpim | 16 May 2002 17:49

IESG comments on draft-ietf-vpim-hint

Overall, draft-ietf-vpim-hint is a clean specification. Message-Context is a
rather powerful feature, since it provides a signal to an application to
organize its behaviors in possibly comprehensive ways.  The IESG believes that
it should be used only when the quality of a message-context-class has been
well-reviewed and has good support, and that therefore the vendor-specific type
of message context-classes should not exist.  

Having them exist and require nothing more than IANA registration is
inconsistent with the well-taken points in the security considerations about
ways that poorly designed or abused hints can cause trouble.

The change the IESG proposes is simply to eliminate the "vnd." form and the
language about just registering these, in favor of all future ones following
the IANA considerations and having an RFC specification.

Old:

> 
>         vnd.token = <Vendor-specific, private token> 
>     
>    Note: The values for Message-Context must be either IANA registered 
>    values or experimental, vendor tokens.  This ensures that user 
>    agents from different vendors will interoperate and perform in a 
>    uniform manner without an undue burden on the vendors. 
>     

New:

> 
>    Note: The values for Message-Context must be either IANA registered 
>    values following the directions in the IANA Considerations.
>     

Other references to vnd in the ABNF need to be deleted.

This new text is consistent with the i-d's IANA Considerations.
The current IANA Considerations is reasonable (Spec Required).

Additional fixes are needed in the ABNF, as follows:

- It needs to use the RFC 2234 form, which means '/' not '|' and it
  needs to cite 2234.
- The registration reference to Section 8 should be to Section 9.
- Prose values (<...>) may not have carriage returns in them, so the
  definition of "token" is bad.
- It isn't clear if the "[8]" is a reference to RFC 2045 or to section 8.

If the authors and WG insist that a vnd registration is needed,
the IESG wants to insist on it being Specification Required anyway.  If
we do allow "vnd", the ABNF has two more errors to fix.

- Rule names may not have periods, so "vnd.token" should be renamed to
  "vnd-token" (or something).
- vnd-token doesn't set requirement to start with "vnd." as it is now.

				Ned
----------------------------------------------------------
This message was sent to you, since you are subscribed to
vpim <at> lists.neystadt.org. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo
Permalink | Reply | 0 comments |
headers
NED+vpim | 19 May 2002 18:52

RE: IESG comments on draft-ietf-vpim-hint

> In my opinion ability to extend Message-Context with new values is
> imperative.

The IESG isn't suggesting that extensions not be possible. The IESG is only
suggesting that there has to be some accountability for the extensions that are
created in order for this mechanism to have any chance of interoperating.

> Would the following suggestion be consistent with IESG view?

> 1) Allow x-message-context tags for proprietry implementations

Given the incredibly poor history of x- tags in other protocols I see no chance
the IESG will buy into this. Heck, I didn't have a problem personally with
vendor-specific tags, but I have a big problem with x- tags.

This also begs the question of why, since coding support for a new sort of
message in a client is unquestionably a significant undertaking, writing a
short description of it is seen as so onerous.

> 2) Allow registering new message-contexts by issues new RFC.

					Ned
----------------------------------------------------------
This message was sent to you, since you are subscribed to
vpim <at> lists.neystadt.org. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo
Permalink | Reply | 0 comments |
headers
NED+vpim | 20 May 2002 16:39

RE: IESG comments on draft-ietf-vpim-hint

> I was not among the originators of this RFC, so please regard my comments as
> personal ones and not representing whole goup.

> > > 1) Allow x-message-context tags for proprietry implementations
> >
> > Given the incredibly poor history of x- tags in other
> > protocols I see no chance
> > the IESG will buy into this. Heck, I didn't have a problem
> > personally with
> > vendor-specific tags, but I have a big problem with x- tags.
> >
> > This also begs the question of why, since coding support for
> > a new sort of
> > message in a client is unquestionably a significant
> > undertaking, writing a
> > short description of it is seen as so onerous.

> It appears to me to be non-realistic. When we had discussions in the group
> regarding specific values some contraversial ones were taken out with
> argument that they are not generic enough and can always be handled using
> x-context approach.

There's a huge difference between the items that appear in the core
specification of an extensible facility, standardized items that appear
subsequently, and items specified by vendors later. In particular, the bar in
the first case is extremely high. The bar in the second and third cases is 
much lower.

In other words, saying that something is too controversial for the base
specification is not the same as saying it is unsuitable for specification
later. Indeed, base specifications of facilities have a way of introducing
clarity and ordering that facilitates subsequent development.

> I know that in systems we make we quite often introduce experimental
> contraversioal message-contexts (IM, mms, video, picture-messages, etc.),
> which sometimes evolve into generic ones and sometimes are not used outside
> of prototype or customer-specifc system.

Then there's no need to bother anyone with any of it.

> Blocking this from happening will induce using additonal header like
> x-message-context for these cases with its own values.

The experience with media types has been exactly the opposite. x- types created
problems rather than solving them.

Additionally, if the demand for this feature is sufficient to induce such
behavior, I fail to see why we're not drowning in a plethora of random header
fields of this sort.

> In my opinion this will not make message-context more generic, rather make
> handling more complicate and less robust.

Well, the present document doesn't allow for x- values either, so it would seem
the consensus of the group is against you on this.

Remember, while the IESG would like to see vendor contexts eliminated, it
doesn't insist on it. All the IESG insists on is that there be some
specification of the various message contexts available somewhere. This is more
or less equivalent to how media types are handled today.

				Ned
----------------------------------------------------------
This message was sent to you, since you are subscribed to
vpim <at> lists.neystadt.org. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo
Permalink | Reply | 1 comment |
headers
Werbelow, Wayne L (Wayne | 23 May 2002 22:07
Favicon

VPIM Interoperability Event at the Open Group Conference in July.

Hi,

The Open Group (www.opengroup.org) has offered to host a VPIM Interoperability Event at their Conference in Boston the week of July 22 - 26.  Glenn Parsons asked me if Avaya would be willing to lead the event and we have agreed to do so.  However, we need to get a quick "show of hands" for how many vendors would like to participate in the event before we commit to spending lots of time and effort into producing it.

The Open Group would provide the rooms, network hook-ups, telephony connections, marketing, etc. for the event.  Each vendor would need to provide their voice mail system (or at least access to it beyond their firewall), any necessary laptops, monitors, keyboards, and technical expertise on VPIM and their own system.  Also, each vendor would need to pay an event registration fee of $1000 (if you are already a member of the Open Group) or $3500 if you are not a member. 

The event would be similar to previous VPIM events (Bake-offs) and would allow many vendors to interop test with all of the other vendors.  This would also give some vendors a chance to regression test some products that may have been updated since the last interop event.

The Avaya Interchange product (a voice mail networking protocol converter) now supports VPIM (as well as several other existing protocols) and is Generally Available as of January this year.  It could be used to connect all of the vendors' systems together into one large VPIM network.  Obviously, individual connections would still be needed for point-to-point testing. 

If you are interested in participating in this event please contact me as soon as possible so we can continue with the planning.  Once I know your level of interest I will work with you to provide more information about the event and to get more information about your system and what you will need to connect to it.  If you know of someone who might be interested and they are not on this VPIM e-mail list, please forward this message to them.

Thanks,

Wayne Werbelow
Interoperability Test Coordinator
Avaya Interchange Project
Avaya, Inc.
1300 W. 120th Ave.
Westminster, CO 80234
303-538-0455
werbelow <at> avaya.com

Permalink | Reply | 0 comments |

Gmane