Unless the feature is broken to start with without whatever it is
people are claiming is necessary, I would like people to keep
the spec simple so we are more likely to see the spec's adaptation.
.. Focus on basic level of interoperability..
Though that's not to say that we should withhold ourselves
from adding text describing why the feature currently deployed
out there may be unsafe with some description of what
implementers can do to make it more secure..
Regards
Shida
On 29-Apr-09, at 10:22 PM, Elwell, John wrote:
I agree - I would like something to be said about it.
John
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Francois Audet
Sent: 28 April 2009 16:13
To: Michael Procter; Hutton, Andrew
Cc: [email protected]; Scott Orton
Subject: Re: [BLISS] Comments
ondraft-procter-bliss-call-park-extension-04(AutoRetrieve proposal)
Basically, I think a CallPark without an autoretrieve is
effectively an "unsafe" feature, since it will result in
users (typically customers) to wait forever in the
parking space.
-----Original Message-----
From: Michael Procter [mailto:[email protected]]
Sent: Tuesday, April 28, 2009 02:00
To: Hutton, Andrew
Cc: Audet, Francois (SC100:3055); [email protected]; Orton,
Scott (RICH1:B620)
Subject: Re: [BLISS] Comments on
draft-procter-bliss-call-park-extension-04(AutoRetrieve proposal)
2009/4/28 Hutton, Andrew <[email protected]>:
I agree with Francois it would I assume be the Referred-by
header that
contains the URI of the park server and as long as the UA
can match
this against it's local configuration then this will be ok.
That would probably be more straightforward. But it assumes
a particular way of achieving the feature.
I do think we should have a short description of the
auto-retrieve
procedure including an example message flow in the draft.
I'm still not entirely convinced that it belongs in this
draft, although I agree it is an important aspect to consider
in an implementation. I'm also not sure that it is within
scope for BLISS, given that it does seem to be trying to
standardise a feature over and above the level needed for
'basic interoperability'.
However, I am open to persuasion! To that end, I'd
appreciate contributions of text / message flows.
Michael
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
