[IMXPwg] step 2 of section 4.4.2

Graham Klyne GK@Dial.pipex.com
Wed, 27 Sep 2000 15:55:30 +0100


At 10:09 PM 9/21/00 -0700, Marshall Rose wrote:
>okay, this version of imxp-core adds the dns reverse/forward lookup thing 
>that dave was talking about. please read it carefully.


Section 4.4.2
-------------

Beyond the reverse-DNS lookup, there's no hint how stronger authentication 
of a relay might be performed;  e.g. use of authenticated BEEP peer identity.

e.g. add to the steps performed by a relay on receiving a 'bind'

2a.  The relay may also use other information, such as the authenticated 
BEEP peer identity, to decide whether the requested bind operation will be 
accepted.  If it decides that the peer is not entitled to act for the 
requested domain, an "error" element having code 537 is returned.


Section 4.4.4.1, item 3.3
-------------------------
It's not crystal clear when "the recipient is considered to be successfully 
processed".

I.e. is it as soon as the new data element has been sent, or when it has 
been acknowledged by the recipient?  I think it should be the latter.

I think the wording of this section could be clearer;  I suggest:

--
3. Otherwise, the IMXP access service must check that the originator 
endpoint is allowed to communicate with the recipient endpoint (the 
recipient's access entry[9] must contain a "core:data" token for the 
originator), and that the recipient endpoint is currently attached.

If so, a new "data" element, containing only that "recipient" element (and 
no options), is sent to the corresponding application, and the recipient is 
considered to be successfully processed when the data element has been 
acknowledged.
--


Section 5 contradicts section 4.4.4.1
-------------------------------------

[Section 4.4.4.1, item 3.3]
Otherwise, the IMXP access service must allow the originator endpoint to 
communicate with the recipient endpoint (the recipient's access entry[9] 
must contain a "core:data" token for the originator), and the recipient 
endpoint must be currently attached.

If so, a new "data" element, containing only that "recipient" element (and 
no options), is sent to the corresponding application, and the recipient is 
considered to be successfully processed.

[Section 5]
Note that a final relay does not remove any options as it transmits the 
containing element directly to the recipient.


References
----------
Citation [11] draft name is no longer current.


#g

------------
Graham Klyne
(GK@ACM.ORG)