Subject: Re: [Sip] Re: Consent-Framework: Store and Forward (was Re: WGLC comments for draft-ietf-sip-consent-framework-00)

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 25 Nov 2006 10:51:09 +0200

Hi Ben,

per our face-to-face conversation in San Diego, you told me to stress 
the fact that clients need to have a way to know about the consent 
status of their operations. I have added the following sentence to the 
beginning of Section 5.2:

    Clients need a way to be informed about the status of the operations
    they requested.  The Pending Additions SIP event package [13], which
    SHOULD be supported by relays, is a way to provide clients with that
    information.

http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent-framework-01.txt

With this addition, all the WGLC comments should be addressed now. I 
will be submitting shortly.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Hi Ben,
> 
> yes, I agree we should go for option 1. I have added text explaining 
> what to do in that case:
> 
>    Even though store-and-forward servers perform a useful function and
>    they are expected to be deployed in most domains, some domains will
>    not deploy them from day one.  However, user agents and relays in
>    domains without store-and-forward servers can still use this consent
>    framework.
> 
>    When a relay requests permissions from an off-line user agent that
>    does not have an associated store-and-forward server, the relay will
>    obtain an error response indicating that its MESSAGE request could
>    not be delivered.  The client that attempted to add the off-line user
>    to the relay's translation logic will be notified about the error
>    (e.g., using the Pending Additions event package [13]).  This client
>    MAY attempt to add the same user at a later point, hopefully when the
>    user is on-line.  Clients can discover whether or not a user is on-
>    line by using a presence service, for instance.
> 
> 
> 
> Feel free to edit the text above so that you are happy with it.
> 
> Thanks,
> 
> Gonzalo
> 
> 
> Ben Campbell wrote:
>> I'm separating my response about the consent-framework store and 
>> forward issue from the other issues, since I think this one needs more 
>> discussion. Specific's inline
>>
>> On Oct 25, 2006, at 8:18 AM, Gonzalo Camarillo wrote:
>>
>> [...]
>>
>>>> 4.3
>>>>> There are several mechanisms to implement store-and-forward message
>>>>>  services (e.g., with an instant message to email gateway).  Any of
>>>>>  these mechanisms can be used between a user agent and its
>>>>> store-and- forward server as long as they agree on which mechanism
>>>>> to use. Therefore, this framework does not make any recommendation
>>>>> on the interface between user agents and their store-and-forward
>>>>> servers.
>>>> It is not clear to me if store-and-forward servers are a required
>>>> (i.e. normative) part of the consent architecture, or if they are
>>>> just something that might exist. I infer the first, considering the
>>>> draft always assumes the existence of them, and there are clear
>>>> issues about handling permissions when you can't get a MESSAGE to the
>>>> recipient.
>>>> If we are going to normatively require them, then I have some
>>>> heartburn about the fact that there is no specification of how they
>>>> work. I don't expect _this_ doc to specify that, but it should be
>>>> somewhere. In particular, if we are going to architecturally require
>>>> them, we as a community should be concerned about interoperability
>>>> between S&F servers and arbitrary UAs, which this document
>>>> _explicitly_ punts on.
>>>
>>> yes, I agree a clarification is needed. I propose to add the following
>>> text at the end of Section 4.3:
>>>
>>> NEW TEXT:
>>>
>>>    Even though store-and-forward servers perform a useful function and
>>>    they are expected to be deployed in most domains, some domains will
>>>    not deploy them from day one.  However, user agents and relays in
>>>    domains without store-and-forward servers can still use this consent
>>>    framework, although with some limitations.  In particular, relays in
>>>    these domains are not able to request permissions from users that are
>>>    off-line.
>>>
>>
>> I'm still uncomfortable with this. The proposed text still implies 
>> that S&F servers are needed for a "complete" consent-framework 
>> solution, and that the framework essentially fails without them.
>>
>> 1) Specify consent-framework behavior from the assumption that no such 
>> thing exists, at least in the common case. That is, talk in some 
>> detail about what you do when the MESSAGE requests fail, and whether 
>> you should retry later, how often to retry, etc. We could point out 
>> that if an S&F type server were present, then an offline target should 
>> not cause the MESSAGE request to fail, but that would be about all we 
>> could say about them.
>>
>> 2) Recognize that the consent-framework has an architectural 
>> dependency on S&F servers, and have one of the related WGs go down the 
>> path of specifying one, to be normatively referenced here.
>>
>> I realize that option 2 is not a tenable solution, as it would block 
>> progress on the consent-framework for some time. My opinion is that we 
>> should go with option 1. If at some time in the future we standardize 
>> an S&F server, we could discuss their use in more detail in a separate 
>> draft.
>>
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Ben Campbell <[email-masked]>
Date: Sat, 25 Nov 2006 12:24:24 -0600

I would add a sentence describing the consequences of not having a  
way to get the status. Otherwise, it looks good to me.

Thanks!

Ben.

On Nov 25, 2006, at 2:51 AM, Gonzalo Camarillo wrote:

> Hi Ben,
>
> per our face-to-face conversation in San Diego, you told me to  
> stress the fact that clients need to have a way to know about the  
> consent status of their operations. I have added the following  
> sentence to the beginning of Section 5.2:
>
> With this addition, all the WGLC comments should be addressed now.  
> I will be submitting shortly.
>
> Cheers,
>
> Gonzalo
>
>
>
> Gonzalo Camarillo wrote:
>> Hi Ben,
>> yes, I agree we should go for option 1. I have added text  
>> explaining what to do in that case:
>>> forward issue from the other issues, since I think this one needs  
>>> more discussion. Specific's inline
>>>
>>> I'm still uncomfortable with this. The proposed text still  
>>> implies that S&F servers are needed for a "complete" consent- 
>>> framework solution, and that the framework essentially fails  
>>> without them.
>>>
>>> 1) Specify consent-framework behavior from the assumption that no  
>>> such thing exists, at least in the common case. That is, talk in  
>>> some detail about what you do when the MESSAGE requests fail, and  
>>> whether you should retry later, how often to retry, etc. We could  
>>> point out that if an S&F type server were present, then an  
>>> offline target should not cause the MESSAGE request to fail, but  
>>> that would be about all we could say about them.
>>>
>>> dependency on S&F servers, and have one of the related WGs go  
>>> down the path of specifying one, to be normatively referenced here.
>>>
>>> I realize that option 2 is not a tenable solution, as it would  
>>> block progress on the consent-framework for some time. My opinion  
>>> is that we should go with option 1. If at some time in the future  
>>> we standardize an S&F server, we could discuss their use in more  
>>> detail in a separate draft.
>>>
>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 26 Nov 2006 13:03:15 +0200

Hi Ben,

> way to get the status. 

I have added the following sentence:

Clients need a way to be informed about the status of the operations
they requested. Otherwise, users may be waiting for an operation to
succeed when it has actually already failed.

> Otherwise, it looks good to me.

Good. I will submit the new revision then.

Thanks!

Gonzalo

---

From: Ben Campbell <[email-masked]>
Date: Sun, 26 Nov 2006 11:47:27 -0600

I think it still needs to be a little more precise on the nature of  
the failure that can occur if you don't track the status. Something  
to the effect of :

"... In particular, if the target of the consent request was not  
reachable, the client needs to know to retry the request later."

Thanks!

Ben.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 26 Nov 2006 21:28:56 +0200

Hi Ben,

OK. The text now reads:

Clients need a way to be informed about the status of the operations
they requested. Otherwise, users may be waiting for an operation to
succeed when it has actually already failed. In particular, if the
target of the request for consent was not reachable and did not have
an associated store-and-forward server, the client needs to know to
retry the request later.

Thanks,

Gonzalo

Ben Campbell wrote:
> I think it still needs to be a little more precise on the nature of the 
> failure that can occur if you don't track the status. Something to the 
> effect of :
>