Subject: Re: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-00.txt

From: "Anton Tveretin" <[email-masked]>
Date: Fri, 20 Feb 2015 03:47:53 +0500

Mary, Dale, and all,
Let me answer in a single post.
Thank you for your replies.
I tried to found an equivalent RFC about a year ago, on request by Paul. There are none.
https://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 is closest, (and -03 version IIRC is 
more detailed) but it I was withdrawn by authors. So I think it is not binding for me or the 
IETF, and I do not consider it.
Also, I warn that some memos use "call pick-up" to denote other services, as call parking or 
even call holding. I think they are irrelevant, as well.
As of RFC 4235: I believe that controller makes a decision about incoming call (either to pick 
it up, or reject, or let alerting entity answer etc.) For this, it needs as much information as 
possible; it might need Subject, History, media types (e.g. to not intercept incoming faxes and 
files). So for XML we should add more and more elements and attributes. I believe that a SIP 
message is much better way to represent a SIP message than XML. (Not counting 
http://blog.codinghorror.com/xml-the-angle-bracket-tax/ ) Maybe this is not the ideal way 
though, as both parties have to parse the same message.
As for REFER/Replaces: for me, this behaviour is not obvious, and does not follow from RFC 
3515. Is it formally defined anywhere except 
https://tools.ietf.org/html/draft-worley-sipping-pickup-01? I think that url-encoding URIs into 
URIs and further into URI is an ill way to do things (like XML?)
MBus drafts seemingly belong to a different level, more like API.
Regards,
Anton.