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

Ben, Paul:

See inline comments

On 10/09/2012 18:49, Paul Kyzivat wrote:
> 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.

I would accept that compromise if there is a lot of pressure. Let's be 
pragmatical. The Internet is full of RFCs with normative statements that 
have been updated by other documents changing the initial normative 
behavior. This is a common practice in IETF documentation.

So, I don't see a problem in leaving the text as is, and then, if need 
arises, create another hypothetical document that updates this in a 
number of normative statements for the addition of a few hypothetical 
features.

And this will make the current text very clear: "if you implement THIS 
spec you need to do this". If you implement some other spec, that other 
spec will tell you what to do.

/Miguel



>
> Thanks, Paul _______________________________________________ Simple
> mailing list [email protected]
> https://www.ietf.org/mailman/listinfo/simple
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain