Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(AutoRetrieve proposal)

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: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]
>> On Behalf Of Francois Audet
>> Sent: 28 April 2009 16:13
>> To: Michael Procter; Hutton, Andrew
>> Cc: bliss@ietf.org; 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:michael@voip.co.uk]
>>> Sent: Tuesday, April 28, 2009 02:00
>>> To: Hutton, Andrew
>>> Cc: Audet, Francois (SC100:3055); bliss@ietf.org; Orton,
>>> Scott (RICH1:B620)
>>> Subject: Re: [BLISS] Comments on
>>> draft-procter-bliss-call-park-extension-04(AutoRetrieve proposal)
>>>
>>> 2009/4/28 Hutton, Andrew <andrew.hutton@siemens-enterprise.com>:
>>>>
>>>> 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
>> BLISS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bliss
>>
> _______________________________________________
> BLISS mailing list
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss