Glenn Parsons (gparsons@nortelnetworks.com)
Mon, 14 May 2001 11:15:53 -0400
Thanks for your review!
My comments are below.
Glenn.
> ----------
> From: James P. Salsman
> Sent: Wednesday, May 9, 2001 11:26 pm
> To: vpim@lists.neystadt.org
> Subject: Re: WG Last Call on VPIM v2
>
> I read through draft-ietf-vpim-vpimv2r2-02.txt without finding any
> real serious issues or problems, but I did want to ask about these
> four minor points to maybe help clarify the document:
>
> In section 4.2.8 [Page 14], the Receive Rules for the Reply-To
> header contains this sentence: "If only one address of the
> originator is supported in the message store or in the next-hop
> protocol from a multi-protocol gateway, the address in the 'From:'
> field MUST be used and the 'Reply-To' field MAY be silently
> discarded." What does that mean? I can't figure it out. I don't
> understand either of the disjoint anticedent conditions.
>
The point is that legacy voice mail systems that may be behind a VPIM
gateway can only handle one originator. When presented with two, a choice
needs to be made. Perhaps some better wording would help...
> "If the receiving system (e.g., multi-protocol gateway) only supports one
> address for the originator, then the address in the 'From:' field MUST be
> used and the 'Reply-To' field MAY be silently discarded."
>
> Also, it
> seems strange to discard the Reply-To field without some kind of a
> warning, or some attempt to send to it in addition to the "From"
> field, which seems allowed but not manditory, right?
>
The reasoning was that since some systems could not deal with it and that
there remains some controversy over its exact use, VPIM systems should not
generate the Reply-To field and its use should be further discouraged by the
fact that it may be discarded.
> In section 4.2.10, and probably other places, there is a reference
> to [V-MSG] (RFC 2423), even though it seems like that references
> was either superceded or maybe just duplicated in Appendix E,
> section 18.2 [Page 55]. If RFC 2423 is being superceded here, it
> would be best to point to the appendix instead, but if it is just
> simply duplicated, then I guess it might be better to reference both,
> to save the reader a little time.
>
RFC2423 is being superceded. This was a spot I missed. Thanks.
> In section 4.3.2 [Page 18], in the next-to-last sentence of the
> first paragraph, the phrase "audio contents MUST always be of type
> inline.", should probably instead end "of disposition inline."
>
Good point, we'll fix that.
> In the first row of the table in Appendix C [section 16, Page 52],
> shouldn't the nondelivery code for a busy line be 4.3.2 instead of
> 4.4.0? RFC 1893 seems to indicate 4.3.2 would apply ("Examples of
> such conditions include ... excessive load....")
>
4.3.2 would indicate to me that the system answered the call, but quickly
dropped it due to overload. I would suggest 4.4.1 would be better for a
'busy signal',
X.4.1 No answer from host The outbound connection attempt was not answered, either because the remote system was busy, or otherwise unable to take a call. This is useful only as a persistent transient error.
but then it can not be distinguished from 'ring-no-answer'. Perhaps that
would still be better though then 'Other'. Greg?
> I hope this gets lots of interoperable implementations soon.
>
We already have numerous for RFC2421, I think most of those will be
interoperable with this revision as well.
> Thanks to Greg and Glenn for the great work.
>
Thanks for the vote of confidence.
This archive was generated by hypermail 2.0b3 on Mon May 14 2001 - 18:33:46 IDT