Re: Yet more issues to resolve

[Christopher Ferris <chris.ferris@east.sun.com>]

Ian,

Thanks for sending these out. Some comments below.

Cheers,

Chris
ian.c.jones@bt.com wrote:
> 
> TR&P people,
> 
>         Sorry this is late - the real world gets in the way occasionally.
> 
> The following issues may now have been overtaken by events but we need to at
> least acknowledge this so that I can get the database of issue and changes
> update by the New Year.
> 
> ####
> Issue 15
> Title - RM Info
> Detail - 7.9.4  - RM Info: why isn't this in routing header?
> 
> Proposal -  Move to Routing Header
> Resolution -
> Response By - December 21

I have to disagree with this. The ReliableMessagingInfo
element applies to the message, not to a particular hop
along the way. Note that David has crafted a revised section
on RM in the draft we've been collaborating on which we
hope to get to the list today (although, we recognise that
it still needs work). 

> 
> ####
> Issue 16
> Title - TPAInfo
> Detail - Add new section containing all TPA(CPA) information
> 
> Proposal - see above
> Resolution -
> Response By -

This one I'm not sure I understand. I thought that we agreed
in Tokyo to flatten the TPAInfo section by moving all of
the child elements to be direct decendants of Header.

What information was missing from TPAInfo anyway? I'm not
clear on what the proposal really suggests.

> 
> ####
> Issue 17
> Title - Sequence number
> Detail - 7.10 SequenceNumber as defined adds little or no value over the
> MessageID element required in MessageData.  Recommend removing this section
> and the corresponding references to SequenceNumber in later  examples, the
> DTD and the schema.
> If this section remains, must define the exact content of the SequenceNumber
> element when the numeric value is greater than 999.  Is the next value
> "1000" or "1,000"?  Is the text for the maximum value  "999999999" or
> "999,999,999" or are both allowed (and equivalent)?  Side note: Numeric
> formats vary by locale and a comma is not always the thousands
> If this section remains, "long time" should be defined.  At least, refer to
> a TPA which makes this concrete for a specific trading relationship or
> mention later text on this subject (if any).
> 
> Proposal -
> Resolution -
> Response By -

Since we're going to spec the schema using XMLSchema, we can
be more precise in the typing of elements and attributes.
I agree that the spec needs to be tightened up for this
particular element.

I'll have to review David's revision of RM to see what that
has to offer.

> 
> ####
> Issue 18
> Title - URI definitions in RM
> Detail - 7.10 - SenderURI, ReceiverURI and ErrorURI are not defined.  Are
> they identifiers or service locations?  From later discussion in this
> document, it appears that ErrorURI is a service location at which error
> responses may be received.  The other two aren't discussed much.  However,
> I'd recommend they be defined similarly to the PartyId elements in the
> Header (i.e. the parties participating in the current leg of the journey).
> That requires adding a context attribute to SenderURI and ReceiverURI and
> (potentially) renaming the elements.  Alternatively, SenderURI and
> ReceiverURI may somehow identify the service location used in this
> particular leg (this is probably redundant information for ReceiverURI with
> the transport destination and SenderURI may not exist -- not all senders are
> reachable in return).
> 
> Proposal -
> Resolution -
> Response By -

I assume that the subject refers to URI elements in RoutingHeader
not RM. Agree that these need to be more precisely defined.
As to defining them similarly to the PartyId element...
I had actually proposed to David in our discussions that
instead of defining different elements, that we re-use
To and From but with precise wording that the PartyId
MUST be an URL form of URI (e.g. something addressable).

This also brings to mind a security issue (possibly) as
if an intermediate signs a header (with the added RoutingHeader
element) then it MAY be important to be able to identify
the intermediary with the specific RoutingHeader. I hadn't
thought of this before, but it MAY be important to consider.

> 
> ####
> Issue 19
> Title - Persistent storage
> Detail - 7.11 - "Persistent storage" actually lasts how long?  Is the
> original message deleted by the Messaging Service immediately after
> receiving an acknowledgement?  In the case of an error, which is reported to
> the sending application (party), does that report also result in deletion of
> the original message from the persistent storage?
> What information does the Receiver store persistently in this step?
> Recommend storing the MessageID of the original message and the entire
> response document.  To check for "exactly the same as the original message"
> as described on line 828, may be necessary to store entire original message
> or its checksum as well.
> 
> Proposal - This is out of scope of the TR&P if required it should be in the
> CPP/CPA
> Resolution -
> Response By -

David has added a section on persistence in his RM draft
proposal. It doesn't get into "how long" as this is correctly
identified as being something that the parties MUST agree
upon and have reflected in the CPA. A new element is being added
to the CPA for this purpose (e.g. to capture the persistenceDuration
with which a message is to be archived).

> 
> Ian Jones
> E-Commerce Engineer
> 
>
begin:vcard 
n:Ferris;Christopher
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard