[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] MSRP: Miscellaneous REPORT issues

The forthcoming draft adds a Status header field to the REPORT method, and makes the use of DSN optional.

There has been some question, recently, whether we need DSN at all. For the amount of information carried in the DSN, it would not be too big an effort to make optional REPORT method headers that can carry the same thing, and have it better matched to MSRP.



On Jul 18, 2004, at 1:33 AM, Eric Burger wrote:

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



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