Greg (gregv@lucent.com)
Tue, 5 Feb 2002 06:53:25 -0700
In implementing the VPIM schema, we have encounter problems with the
semantics of the VPIMSupportedEncodingType attribute. This attribute
appears to have two purposes that seem to be tangled together.
First, the encoding type is supposed to list the supported audio encodings
such that a vendor-X system can recognize that when sending to another
vendor-X system, a proprietary or other standard encoding can be accepted.
It is also useful to deploy new standard encodings within a given network
such as mu-law within a LAN. For this purpose,. the use of the MIME
content-type sorta works ... it does not provide a means to declare support
of WAV encapsulated GSM or other WAV encapsulated codecs.
A second more UMish usage is to indicate to the sender whether a recipient
can accept a particular message "context". Can I forward a fax to your
mailbox? How about an email? Initially we expected that this could be
represented by enumerating the top-level content-types of the relevant
messages, such as Multipart/voice-message and Image/TIff. What this quickly
turns into is a laundry list of very many content-types, a list that does
not really help figure out what the recipient can accept when you consider
all the parameters such as Charset that are necessary.
I have considered incorporating the full content-negotiation feature
descriptions, but that seems to be an overkill. As we learned in the
wonderfully educational message context discussions, what really seems to be
needed is an indication of whether the recipient can accept a voice message,
a fax message, a short-text, or multi-media message. These values are
enumerated in the message context draft.
While in my perfect world these attributes would point to strict profiles, I
think they will work quite well as a hint. Many systems from many vendors,
deployed in different ways by many corporate or service provider customers
will have variations in the supported details. For that reason I am
comfortable with the vaguer notion of a "hint". In that context, it is
still acceptable to NDN a message if the recipient can't accept a particular
media type.
So, I'd like comments on a proposal for the following.
1) Change VPIMsupportedEncodingTypes to be a list of audio codecs, say,
registered Audio/* subtypes. Rename the attribute to be
VPIMsupportedAudioFormats.
2) Add an attribute for VPIMsupportedMessageContexts. This attribute will
point to the message context RFC and the IANA message context registry for
valid values.
Comments? I hope to have a revised draft out this week.
Greg V.
-----Original Message-----
From: Vaudreuil, Greg M (Greg)
Sent: Monday, December 10, 2001 3:42 PM
To: 'IETF VPIM List'
Subject: [VPIM] VPIM Schema Bar Bof
I would like to host a conversation about the LDAP VPIM schema tomorrow at
1:00 in the foyer (front) lounge in the Great America. The topic is the
storage and handling of the spoken name contents in the directory.
The current VPIM schema specifies that the spoken name, recorded in
32kADPCM, be stored in the directory. In service providers hosting tens of
millions of records, and in several enterpriese topologies, it may make more
sense to store a pointer in the VPIM schema to an alternate repository,
presumably the voice mail machine itself. Neither the storage in a central
place nor the distributed storage are idea. The distributed storage
requires an additional query and the commensurate delay.... and the central
storage requires more storage as well as logic in the voice mail system to
update the central directory.
A related data item is the mailbox status. The mailbox status is a dynamic
attribute, that while it does not change often, does change more often than
is attractive for a large directory. This status may resemble more closely
a presence attribute. Does it make sense to store this centrally? How
about on a distributed basis?
The questioni to be discussed and resolution to be proposed is whether to
define the schema to support both modes (centralized or distributed) or only
one, and if both, how to unambigously determine the mode without requiring
additional query round-trips.
Greg V.
-----Original Message-----
From: Vaudreuil, Greg M (Greg)
Sent: Thursday, June 21, 2001 9:31 AM
To: Glenn Parsons; marusj@nortelnetworks.com
Cc: 'IETF VPIM List'
Subject: [VPIM] Calling ID Draft Comments
Thanks for the updated draft. I have a number of comments.
First, this is a very restricted draft limited to enterprise or residential
integrations. Such service provider features as reply by phone call to
blocked caller-ID can't be supported using this standard. While a solution
to this problem is a bit more "interesting", I would like to see us explore
some options. Also we dismiss the other signaling information that may be
of great use in unified communications applications including called number
and originally called number... Is the idea we can add these in the future
as additional header lines?
I would like to see an explicit value for a caller-ID blocked message. It
is useful to distinguish between unavailable and blocked in presenting this
information to the end-user.
I would prefer the character set for calling name be explicitly defined as
ISO 8859-1. It appears from the description in the draft that all
calling-name standards are proper subsets of that character set. This
avoids use of the encoded word for character sets beyond ASCII-like or IA5
sets.
Truncated caller-ID is a real problem that I would like to see better
addressed. Is the truncation a specific problem of a specific PBX? In my
service, International caller-ID is either fully available or not available.
The truncated to ten digits is dangerous and there is seemingly no way to
automatically detect that failure mode.
My preference is to define the caller-ID field to be explicitly labeled as
E-164. Internal extension numbers aren't "caller-ID" and in many cases will
present numbers that can't be represented in E.164. I suggest private dial
plan stuff be a private matter.... Maybe using an explicitly defined
extension value in the syntax.
Greg V.
This archive was generated by hypermail 2.0b3 on Tue Feb 05 2002 - 15:53:42 IST