Notes, SIMPLE Working Group, IETF 60

August 2, 2004, 1300

Chaired by Robert Sparks and Hisham Khartabil

Meeting called to order and agenda accepted.

Topic: Chairs Report

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

Core SIMPLE docs in Auth 48 and should complete soon.

Project plan presented.

Topic: MSRP Base, Ben Campbell

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

Slides presented.

Discussion of Status and Changes follows.

Reports changes: Discussion: There is no minimum

size of an MSRP message. Can a report get chunked by a relay? Ans:

No. Reports don't get chunked.

Framing: No discussion apart from changed reviewed in slides.

Chunking: Changes reviewed in slides. Noted that recent email

suggested that draft should note that S/MIME must be applied before by

chunking. Also, guidance received that chunking be imposed at 2kB boundary.

VISIT: Removed from spec, replaced with a utilization of SEND, which

could be empty. No further discussion in meeting.

Transport and Protection: No discussion.

Max-Size: No discussion.

Discussion of Open Issues follows.

Issue: Terminating long-message transmissions without accidental

rendering of incomplete message: Possibility of "abort" flag on the

transmission raised. There seems to be a consensus to adopt this

approach.

Issue: Range header: Proposed: if you think there is any chance that a

message might be interrupted (over 2k) go ahead then the last field in

the byte range header should be set to "*". There seems to be a

consensus to use this approach in conjunction with the "abort" flag.

Issue: MSRPS vs MSRP. Is this justifiable due to DNS-cert matching

resolution requirements and/or NAPTR options? Rough conensus seems to

be that the usage is justified.

Issue: Report Handling. Discussion of whether report headers can be

present in a REPORT request -- answer is no, they are not

allowed. There may be an error in the spec or examples that needs to

be corrected. These headers only apply to SEND.

Issue: Extensibility. Do we need versioning? Proposed that a URL

parameter for version be added. This relates to whether we wish to

develop an innate extension negotiation mechanism as per SIP, use

completely new protocol definitions and negotiate with SDP. This could

fall back to making a SIP option tage for understanding the version

option. Action item: Document the selected extension approach as part

of the XCAP spec.

Issue: What does max-size mean? How does it apply to body parts inside

of multipart? Proposed that it apply to any matching body part,

regardless of encapsulation. For example, if a multipart has text,

html, and text parts, then these qualify as three individual

parts. Suggested that we have a max-size apply across the whole set of

multiparts. Ensuing discussion indicates a lack of clear

requirements. Proposed: We seem to have sufficient annecdotal evidence

that justifies a max-size parameter that applies to all body parts. We

should adopt this now, and unless someone comes up with a good

justification for part-by-part sizing, we drop that requirement. There

seems to be consensus for this approach. Proposed approach is a new

a-line entry "max-size". Discussion: Is this data "a hint" or

normative behavior for the sender? There seems to be consensus that

it is a hint.

Issue: Page vs. session mode. Should there be a discussion of when to

use each mode? Proposed that this belongs in a SIMPLE architecture

document, not in MSRP. There seems to be consensus not to discuss this

in the MSRP spec.

Issue: DSN. Now that we have have status information in a report, what

does DSN do for us? Is there a reason to keep it? Seems to be

consensus that we do not need DSN body parts any more. Proposed:

Change from SHOULD send DSN to MAY send DSN, and to deprecate body

preparation to be free-form text. Alternate proposal: Drop DNS

discussion from draft entirely. Question: Do we allow bodies on

REPORT? Proposed: No. Counterproposed: Yes, up to 2k, negotiated as

an SDP option. Message-context header discussed as a

possibility. Suggested that this needs to be handled as part of the

alleged SIMPLE architecture document.

Further discussion: Do we need guidance on resource starvation and

utilization, like weighting algorithms and discard and stuff?

Discussion was inconclusive.

Issue: being able to put information like a "From" header in the MSRP

request that identifies the source so that intermediaries like mixers

can relay this on. This might be applicable to an MSRP conferencing

model. Even though the focus knows who is talking, how does it pass

this on to the other recipients so that utterances can be associated

with sources? Clarifying question: Given that the focus might be

multiprotocol, should the utterance identifier be a

protocol-indicating URI? Question -- Would this identifier be

mandatory, or optional? Comment: The source can present its identity

in CPIM. Issue: If this is an "anonymous" identity, how does this

correlate to the roster? We would need some way for the focus to

transmit the focus-assigned anonymous identity value to the user agent

for inclusion in the CPIM wrapper. Thought: Wow, this is just like the

proxy identity-rewrite problem in SIP, isn't it? Comment: Something we

did in SIP that was a mistake was the failure to distinguis between

identity-targeted headers vs. end-to-end significance. The

CPIM-wrapper method is clearly end-to-end, and may as a result be

better than the SIP approach. Conclusion: Author will attempt to

document use of CPIM with focus-provided identifier valuesd to

addresses anonymous-conference requirements.

Topic: MSRP Relays, Rohan Mahy

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

Slides presented.

Status: Document is known to still contgain inconsistencies. Poll on

reading of base draft: about 10% of room. About 3% indicated that they

have read the relay draft.

Changes summarized.

Issue: Refreshing AUTHs. Proposal that client periodically send new

AUTH requests, targeted to a specific URI in the

To-Path. Consequently, a full refresh would do a "full telescope" but

not necessarily in order of traversal. Discussion: This conflcts with

refresh approach chosen in Canada interim meeting two years ago. This

might have been related to the n-way timer negotiation as envisioned

during the Ottawa meeting. Since the new model is one of one-to-one

relationships between clients and relays, the proposed approach seems

to work better.

Noted: Editor requests that people start sending inconsistencies

between relay and base drafts.

Discussion: The time-limiting aspect of authentication nees to be

clarified.