Glenn Parsons (gparsons@nortelnetworks.com)
Thu, 17 May 2001 15:18:28 -0400
Greg W,
Thanks for your comments and thorough review. My thoughts are below.
Cheers,
Glenn.
> Section 4.2.2 To
> In the SEND RULES it states: "...SHOULD provide a "To:"
> line......recipients SHOULD NOT be enumerated." Why is this? Doesn't
> this
> result in a blank To: field? If it does, why SHOULD the To: field be
> included in the header? I propose that the statement be changed to
> "...MAY
> provide a "'To:" line..."
>
Empty To: lines are allowed in 822 but not in 2822... VPIM v2 is based on
822 (since 822 is a Full Standard and 2822 is only Proposed Standard). But
some systems get confused if there is no To: line which is why we said
SHOULD send one.
Still, I take your point. Let's change it to MAY.
> Section 4.2.6 Return-Path
> 1) Regarding the sentence "Note that if the "Return-path:" is null
> ("<>") (e.g., a call answer message would have no
> return path) delivery status and message disposition notifications MUST
> NOT
> be sent," MDN shouldn't be referenced in this statement, because MDN has
> no
> relationship to the Return-Path: field. I propose that the reference to
> MDN
> be stricken.
>
Good point. Will do.
> 2) Why do the RECEIVE RULES discuss what to do if a system is
> incapable
> of storing a Return-Path: value when the SEND RULES states that an
> originating system MUST NOT send this field?
>
Return Path is added by the receiving system. It is the value of MAIL FROM.
> Section 4.2.10 MIME-Version
> Regarding "Systems conforming with this specification SHOULD include a
> comment with the words "(Voice 2.0)"...This identifier is intended for
> information only and SHOULD NOT be used to semantically identify the
> message
> as being a VPIM message. Instead, the presence of the content defined in
> [V-MSG] SHOULD be used if identification is necessary."
>
> I propose that the requirement for the comment "(Voice 2.0)" be
> dropped,
> based on the statement that it SHOULD NOT be used to semantically identify
> the message. Basically, the comment is useless, and dropping the
> requirement allows us to drop the extra text required to state that we
> "shouldn't use something that we should have in there."
>
Like Content-Description is informational, so is this. I see no value in
dropping it since we have had it and most, if not all, have implemented it.
If we do drop it, we would likely use the same amount of text to explain it
is no longer supported (a la vCard).
> Section 4.2.13 Sensitivity
> Regarding the RECEIVE RULE "If a "Sensitivity:" field with a value of
> "Private" is present in the message, a conforming system MUST prohibit the
> recipient from forwarding this message to any other user. A conforming
> system, however, SHOULD allow the responder to reply to a sensitive
> message,
> but SHOULD NOT include the original message content."
>
> How come the reply should not include the original message?
>
The view was that this was current VM behaviour that we were describing.
> Isn't the
> original message required to provide context for the reply?
>
Perhaps, but not always. The view was that current practice was that
replies to sensitive messages did not (and should not) include the original
message because the user was allowed to set the privacy for the new message.
> Doesn't it seem
> like the original message SHOULD be included, and the reply MUST be marked
> at least as sensitive as the original message?
>
Not in the context were defining.
> Section 4.3.2 Content-Disposition
> Regarding the SEND RULE "Note that there SHOULD only be one instance of
> each of these types of audio contents per message level."
>
> I propose that SHOULD ought to be changed to MUST, or text ought to be
> provided in the RECEIVE RULES to indicate how to handle the receipt of
> more
> than one instance of a given type in a message level.
>
Good point.
Some systems do not use message/rfc822 for forwarded messages and just have
two 'voice-message' contents at the same level. This was the loophole that
the SHOULD covered -- so I am reluctant to make it MUST.
Perhaps I will indicate instead in Receive Rules:
"If more than one instance of the 'voice' parameter type value is
encountered at one level (e.g., multiple 'Voice-Message' tagged contents)
then they SHOULD be presented together."
> Section 4.4 Voice Message Types
> Regarding "The presence of other contents within a VPIM voice message
> is
> not permitted. Conforming implementations SHOULD NOT create a message
> containing prohibited contents."
>
> I infer a MUST NOT from the first sentence, which conflicts with the
> SHOULD NOT in the second sentence. Am I reading too much into the first
> sentence?
>
Hmmm. No you are not. Let's change it to MUST NOT -- it's already that in
the Appendix. But let's add back in some text from 2421 that covers the
intended loophole more clearly:
"In the absence of a bilateral agreement, conforming implementations MUST
NOT create a message
> containing prohibited contents"
>
> Section 4.4.1 Multipart/Voice-Message
> Regarding "The Multipart/Voice-Message content-type MUST only contain
> the
> profiled media and content types specified in this section (i.e. Audio/*,
> Image/*, and Message/RFC822)."
>
> The MUST is aligned with my inference in section 4.4 described above,
> and
> seems to be in conflict with the "SHOULD NOT create a message containing
> prohibited contents" in section 4.4 described above. However the
> requirements are written, I propose that they state, in essence, that
> prohibited contents MUST NOT be included in Multipart/Voice-Message.
>
Agreed, and changed as above.
> Section 5.2.1 DSN Extension
> The NOTIFY and RET parameters are optional when using the DSN
> extension,
> as there is a defined default value to assume when the parameters are not
> present. Why are they bumped up to MUST & SHOULD, respectively, for VPIM?
>
>
Remember VPIM is a profile -- we can elevate or lower requirements in other
standards. In this case, we thought it was critical to the VM requirements
to support the delivery notification features of NOTIFY (i.e., success
and/or failure). We also thought that RET would be useful since most VM
systems wouldn't save the original message and would need a context.
And on your 'editorial' comments:
* 4.5.3 & 4.5.4 are meant to be in 4.5. This was a loosening pushed
by Greg V based on what implementations were doing. Perhaps I should
explain multipart/mixed better...wait maybe that doesn't belong. How about
I move it to 4.5.1 and change the intro text to 4.5 to:
4.5 Other MIME Contents The following MIME contents (with the exception of multipart/mixed)
MAY be included within a multipart/voice-message. Other contents
MUST NOT be included --their handling is a local implementation
issue.
Multipart/mixed is included to promote interoperability with a wider
range of systems and also to allow the creation of more complex
multimedia messages (with a VPIM message as one part).
* References will be updated, but we will use 821/822 instead of DRUMS
(which is only Proposed Standard yet)
* .vpm would be used if your system (or client) saved the
multipart/voice-message as a file to transfer it
* I'll indent Message/D-N & Message/D-S
* I'll change the Reply-to table text to:
Reply Messages |4.9 |C|x| | | | |
send to Reply-To, else From address |4.2.8 |C| | |x| | |
send to non-mail-user |4.9 |C| | | |x| |
* 4.6 and the table both indicate that DSN SHOULD be sent on
non-delivery. Who changed that? It was MUST and I'll change it back.
* I'll change the Notification table text to:
Notifications | | | | | | | |
use Multipart/Report format |4.6, 4.7 |C|x| | | | |
always send error on non-delivery |4.6 |C|x| | | | |
send DSN messages to return-path |4.2.6 |C|x| | | | |
This archive was generated by hypermail 2.0b3 on Thu May 17 2001 - 22:19:49 IDT