> -----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)

> 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)

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...")

-hadriel
_______________________________________________
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

Reply via email to