Re: Multiple body-parts in one INFO

Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email protected]]
>> Sent: Wednesday, December 03, 2008 4:51 PM
>>
>> Is the problem that the document is hard to implement? Or just that you
>> think it has too many words?
>>
>> IMO when we leave ambiguity there will be problems.
>> I would rather see more words than have a brief but ambiguous document.
>> More words do not (necessarily) make the implementation more difficult.
> 
> Of course, and I know document size is not a good measurement of complexity.
> But it does have a psychological effect, fwiw.
> 
> Anyway, no my problem with the draft is it's trying to fix things that either aren't broken, or are broken for everything else and should not be fixed in this specific document. (and I'd debate how they should be fixed, but that's another topic)

You mean the way 3261 was simplified by not saying much about multipart 
and not requiring that it be supported, because that wasn't broken in 2543?

>> We know we have needs for multipart, for things like Geoloc, and
>> probably more, that are orthogonal to other usages. We are headed for a
>> train wreck on that because 3261 didn't say enough about that. The body
>> handlng draft will hopefully address much of that. We just need to try
>> to ensure that other things play well with that.
> 
> Right, so do you also plan to have an update RFC, to change the C-D's of their context's bodies, for each of RFC 3261 (INVITE/ACK), 3265 (SUB/NOT), 3311 (UPDATE), 3428 (MESSAGE), 3262 (PRACK), 3515 (REFER), and 3903 (PUBLISH)?  Most of which have existential proofs of deployed use, and most of which are significant deployment use?  (at least I think INVITE is fairly popular - I could be wrong)

I don't think we need to change common usage of existing deployed stuff. 
We can grandfather the usages.

But by tightening up the required behavior when multipart is being used, 
we may indeed require some deployed devices to be updated to remain 
compliant. Without being updated they will continue to work in those 
cases where they work today. And many of the probably wouldn't have 
worked in some of those currently unused multipart cases anyway.

(We *do* make changes, such as the essential corrections and loop fixes.)

> Or would you rather replace RFCs 3893 (AIB), RFC 3420 (sipfrag), and whatever current drafts do not dis-ambiguate themselves from the deployed message type context's bodies?
> (And for 3893bis at least, I would assert the subject line of such a doc should start with the words "Moving to Experimental...", if not "Deprecation of...")

AFAIK we haven't identified a need to do that. If we do, so be it.

I just want it to be clear under what circumstances you can use multiple 
body parts in a message, and how a recipient of a message containing 
multiple parts figures out how to process it.

Just in the thread we have already heard a explanation of doing it based 
solely on C-T, which is really wrong. So its obviously not clear now.

	Thanks,
	Paul
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip