Subject: RE: [Sipping] Fwd: WGLC on draft-ietf-sipping-content-indirect-01 .txt

From: Adam Roach <[email-masked]>
Date: Tue, 10 Sep 2002 18:13:31 -0500

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> 
> What does "MUST be possible for an application to process 
> messages" mean?
> There is no requirement there: "MUST be possible" isn't a 
> MUST strength...
> I can always decide to do different processing, even though I 
> *could* do it
> the same way.

You do understand that this is a requirements document for a
protocol, and not the protocol specification itself, right?
We're specifying that the protocol that will follow must allow
this mode of operation.

Perhaps it would clarify things if it were phrased
"The protocol MUST allow" instead of "It MUST be possible."

/a
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Sep 2002 11:41:38 +0100

And the rest of the sentence is...?

If I construct from what was previously proposed I end up with

	"The protocol MUST allow an application to process messages"

which seems to make equally sense to me. Normally when I write a protocol specification, my scope is in defining the bits on the line, rather than defining the API or primitive interface. As written, this would only help me do the latter.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> From: Adam Roach [mailto:[email-masked]]
> Sent: 11 September 2002 00:14
> To: [email-masked]'; Sean Olson; Adam Roach; Rohan Mahy;
> [email-masked]
> Subject: RE: [Sipping] Fwd: WGLC on
> draft-ietf-sipping-content-indirect-01 .txt
> 
>