Re: accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)]

On 9/10/12 12:22 PM, Ben Campbell wrote:
>
> On Sep 10, 2012, at 11:00 AM, Paul Kyzivat <[email protected]> wrote:
>
>> - I am a little concerned that if you only allow message/CPIM, that you
>>   will be cutting off a point of extensibility. Some future extension
>>   may need to add something that requires a new mime type here -
>>   presumably one that is a functional superset of message/CPIM. But
>>   a mandatory requirement to include *only* message/CPIM will exclude
>>   such a future focus from being backward compatible with this spec.
>
> I'm not sure that's a bad thing, since there's interop behavior that depends on it's use.  If you use something _other_ than message/CPIM, some one will need to specify how you handle the behavior that is dependent on it.

The issue is with some future implementation that supports simple-chat 
and simple-chat-bis that uses message/CPIM++. The problem then arises 
only in the case that the focus generates the offer. It then wants to 
put "message/CPIM,message/CPIM++" in 'accept-types'.

This should be fine for answerers that support only simple-chat as long 
as they don't get over-picky and declare the focus non-compliant for 
mentioning message/CPIM++. So it's just a matter of not forbidding the 
focus from including something else.

> A possible compromise might be something like "SHOULD include only message/CPIM. While other types might be useful in the future, their use is out of scope for this specification. Any chat mechanism that uses a wrapper other than message/CPIM will need to specify how to encode and interpret sender and recipient information to achieve similar behaviors as in this document."

Yes, something like that could work.

	Thanks,
	Paul