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
