RE: [Simple] MSRP: Miscellaneous REPORT issues

[Eric Burger <eburger at brooktrout.com>]

I can live with DSN bodies being optional, so long as the normative language
is that no body means EITHER success OR failure.  Personally, I'm leaning
toward no body for success because you want information for failure.

We MUST, MUST, MUST chose one and only one meaning for no body.  Having an
empty body sometimes mean success and other times mean failure is a recipe
for major interpretation, and thus interop, failure.

That said, in the MOST STRONG SENSE POSSIBLE I suggest AGAINST having
multiple DSN report types.  That is an invitation for proprietary report
formats EVERYWHERE, making the goal of interoperability evaporate.

If the DSN format is too "heavyweight", then chose something other than
RFC1894.  I hear ASN.1 makes pretty compact messages x-\


By the way, in Section 6.6.2, a device that SHOULD generate DSN's cannot
MUST generate them.  Either they MUST or SHOULD.

Also, a DSN MUST NOT have a Message-Receipt header.  Have to put that in the
security considerations section, too.

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell at dynamicsoft.com]
> Sent: Monday, June 28, 2004 4:21 PM
> To: Simple WG
> Cc: Cullen Jennings; Rohan Mahy; Adam Roach; Hisham Khartabil; Robert
> Sparks; Chris Boulton
> Subject: [Simple] MSRP: Miscellaneous REPORT issues
> 
> 
> This note contains a few additional DSN issues, and the directions 
> proposed by the design team.
> 
> 1) We have had comments that the DSN file format may be two 
> heavy weight.
> 
> We propose that DSN bodies become optional in REPORT methods. 
> We would 
> make it possible to convey basic information in header fields in the 
> REPORT method. A DSN body would become optional for when the 
> reporting 
> device desires a more expressive approach, at its discretion.
> 
> We propose to add REPORT method header fields for MessageID 
> and Status. 
> The MessageID header would corelate with the MessageID of the 
> original 
> content. The status field will include a "scope" token, a 
> status token, 
> and a human readable string.
> 
> Actual DSN payloads are optional. Positive REPORTs MAY contain a 
> payload. Negative reports SHOULD contain a DSN payload.
> 
> 2) Handling REPORTs that occur after a session is complete. 
> Relays are 
> not aware of the precise timing of the opening and closing of 
> a session, 
> so they cannot be prevented from originating REPORTS for 
> sessions that 
> have been closed.
> 
> We propose to specify that a relay SHOULD NOT attempt to generate a 
> report if it has reason to believe it will not be delivered. 
> We do not 
> define how it might have such reason, but will give a couple 
> of examples 
> (perhaps its URL has expired, or it has out-of-band knowledge.) 
> Endpoints MAY accept REPORT requests after a session is over, but are 
> not required to take any action to make it easy for someone 
> to send one. 
> Endpoints SHOULD NOT send DSN for expired sessions.
> 
> There was also a question about how to handle the situation where you 
> have requested positive reports, but We do not state any normative 
> requirements about waiting for REPORT requests to arrive 
> before ending a 
> session, but will discuss choices and their concequences.
> 
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple