ned.freed@mrochek.com
Tue, 05 Feb 2002 07:17:45 -0800 (PST)
> 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.
> ...
> I have considered incorporating the full content-negotiation feature
> descriptions, but that seems to be an overkill.
This is probably true. However, support for feature descriptions provides
one thing you cannot get any other way: Insulation against future
infrastructure changes.
> 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.
Actually, what this suggests to me is that message context needs to be
registered as a media feature so it can be used in content negotiation.
> 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.
I'd suggest "VPIMsupportedAudioMediaTypes" instead.
> 2) Add an attribute for VPIMsupportedMessageContexts. This attribute will
> point to the message context RFC and the IANA message context registry for
> valid values.
I guess I don't object to this. However, the way I'd suggest going about it
would be to register message context as a media feature and add an attribute
for supported feature sets. You can always recommend that this be used to check
for the proper message context value.
Ned
This archive was generated by hypermail 2.0b3 on Tue Feb 05 2002 - 17:24:39 IST