Greg (gregwhite@lucent.com)
Mon, 14 May 2001 18:32:07 -0500
Hi all,
My apologies for sending these concerns to the list so late, but I wanted
to bring up a few things:
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..."
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.
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?
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."
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? Isn't the
original message required to provide context for the reply? 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?
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.
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?
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.
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?
Again, please accept my apologies for putting this out on the list so
close to the end of last call.
Thanks,
Greg White
Lucent Technologies
This archive was generated by hypermail 2.0b3 on Tue May 15 2001 - 02:32:29 IDT