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

Anton,

I read your draft. IMO it needs a lot more text explaining more about 
the problem you are trying to solve, the assumptions you are making, and 
rationale for the choices you have made. As it is I have to guess at 
what you are proposing, and why.

Other points:

* You are proposing to use a subscription to the dialog event package, 
but using content-type sip and sdp to request that the notifier forward 
copies of sip messages that it receives. (And sends?) This is not 
behavior that is defined for the dialog event package (RFC4235), it is 
something new. If you want this behavior you will need to define a new 
event package to provide it.

* You are proposing new sip methods: ANSWER, PICKUP, REJECT. But you 
only mention them. You don't go into any detail of their semantics.

* The controlled device will require inclusion of this new behavior in 
order to participate in such an approach. Do you imagine that all sip 
endpoints would get such behavior? (Unlikely) Or will I have to purchase 
special devices before I can control them? What are the chances that 
such devices will be available for whatever phone system I use?

* This concept is laden with security issues. How would a device know 
whether to authorize this sort of control? In most systems I'm aware of 
most of the security policy is handled deeper in the network, not in the 
end devices. Unless you can propose a security approach that is 
practical this approach will fail.

Are you aware of: 
http://tools.ietf.org/html/draft-ietf-bliss-shared-appearances-15? I 
think it has some overlap with the problem space you are attacking, 
though its approach is much different. The authorization problems are 
much more easily dealt with in that approach.

	Thanks,
	Paul

On 2/5/15 5:29 AM, Anton Tveretin wrote:
> Dear all,
> A long-awaited I-D is finally posted!
> I've spent 25 years to make a telephone a telephone, not this annoying box. ;)
> Surely, there are still issues to discuss.
> For instance, should Reason go to the body, or into header? Is NOTIFY an appropriate
> method there (or should be INFO)? There was a discussion for another I-D.
> Regards,
> Anton.
>
> ------- Forwarded message follows -------
> From:	internet-drafts@ietf.org
> To:	"Anton Tveretin" <fas_vm@surguttel.ru>,
> 	Anton Tveretin <fas_vm@surguttel.ru>
> Subject:	New Version Notification for draft-tveretin-dispatch-remote-00.txt
> Date sent:	Thu, 05 Feb 2015 00:35:57 -0800
>
>
>
> A new version of I-D, draft-tveretin-dispatch-remote-00.txt
> has been successfully submitted by Anton Tveretin and posted to the
> IETF repository.
>
> Name:		draft-tveretin-dispatch-remote
> Revision:	00
> Title:		Remote Call Control and Call Pick-up in SIP
> Document date:	2015-02-05
> Group:		Individual Submission
> Pages:		8
> URL:            http://www.ietf.org/internet-drafts/draft-tveretin-dispatch-remote-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-tveretin-dispatch-remote/
> Htmlized:       http://tools.ietf.org/html/draft-tveretin-dispatch-remote-00
>
>
> Abstract:
>     This memo defines a mechanism by which a SIP user agent could inspect
>     calls at another user agent, and control a call, including picking up
>     for itself.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> ------- End of forwarded message -------
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>