Subject: RE: [Ips] TargetAddress during FFP

From: "Sandars, Ken" <[email-masked]>
Date: Wed, 7 Jun 2006 22:10:33 -0700

Hi Eddy,
 
I'm assuming the TargetAddress=<blah> is being sent in a Text response
PDU by the target. In your scenario, does the initiator send a Text
request PDU? If so, what key(s) are in it?
 
The definition of the key indicates there is nothing illegal about
sending it. Unfortunately, since you are describing a scenario which is
neither a part of a SendTargets response or a part of Login redirect
response, there is no defined action for the initiator. Hopefully the
choice is to not crash!
 
I think the appropriate thing to do is to ignore the key, unless there
are other aspects of the Text negotiation which are broken.
 
Cheers
Ken

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]] 
Sent: 08 June 2006 03:26
To: [email-masked]
Subject: Re: [Ips] TargetAddress during FFP

I don't see a response for this. Does anyone know what to do? i.e.,
should the initiator logout and use the new address, just record the new
address for later logins or just ignore it?

----- Original Message ----- 
From: Eddy Quicksall <mailto:[email-masked]>  
To: [email-masked] 
Sent: Friday, June 02, 2006 11:23 AM
Subject: [Ips] TargetAddress during FFP

What should the initiator do if it receives a TargetAddress=<address>
during Full Feature Phase?
 
Eddy

  _____  

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 8 Jun 2006 07:18:21 -0400

MessageActually I asked the question purposely out of the context of SendTargets because I could not find anything in the spec that required the TargetAddress to be a response to SendTargets. In both cases I would have the same question. I was more wondering what the community does or expects under the two cases.

I'm currently ignoring it but thinking of recording the new address and in the event of a new login using the new address for that. For example, the target may want to send a new target address and then send a request to logout; the new login would use the new target address.

Eddy
  ----- Original Message ----- 
  From: Sandars, Ken 
  To: Eddy Quicksall ; [email-masked] 
  Sent: Thursday, June 08, 2006 1:10 AM
  Subject: RE: [Ips] TargetAddress during FFP

  Hi Eddy,

  I'm assuming the TargetAddress=<blah> is being sent in a Text response PDU by the target. In your scenario, does the initiator send a Text request PDU? If so, what key(s) are in it?

  The definition of the key indicates there is nothing illegal about sending it. Unfortunately, since you are describing a scenario which is neither a part of a SendTargets response or a part of Login redirect response, there is no defined action for the initiator. Hopefully the choice is to not crash!

  I think the appropriate thing to do is to ignore the key, unless there are other aspects of the Text negotiation which are broken.

  Cheers
  Ken

    -----Original Message-----
    From: Eddy Quicksall [mailto:[email-masked]] 
    Sent: 08 June 2006 03:26
    To: [email-masked]
    Subject: Re: [Ips] TargetAddress during FFP

    I don't see a response for this. Does anyone know what to do? i.e., should the initiator logout and use the new address, just record the new address for later logins or just ignore it?
      ----- Original Message ----- 
      From: Eddy Quicksall 
      To: [email-masked] 
      Sent: Friday, June 02, 2006 11:23 AM
      Subject: [Ips] TargetAddress during FFP

      What should the initiator do if it receives a TargetAddress=<address> during Full Feature Phase?

      Eddy

--------------------------------------------------------------------------

------------------------------------------------------------------------------

---

From: David Weibel <[email-masked]>
Date: Thu, 08 Jun 2006 07:55:43 -0600

TargetAddress is typically received during a FullFeature Login
Response of 01/01 (Requested ITN has moved temporarily) or 01/02
(Requested ITN has moved permanently).  I am curious what the
intended behavior outside of those two use cases is for TargetAddress.
Currently, I do record it for the next reconnect but don't use
it as an immediate redirection like the 01/01 and 01/02 describe.

I have never encountered a Target that does the later case.  I
have seen targets doing both the 01/01 and 01/02.

Eddy Quicksall wrote:

>             What should the initiator do if it receives a
>             TargetAddress=<address> during Full Feature Phase?
>