Subject: RE: [SIP] discussion

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 6 Nov 2000 15:39:17 -0000

Some minor tweaks to the original proposal, with the aim of aligning all the
text into a common format, and ensuring that we have a clearly specified set
of sender and receiver requirements, and not with any aim of technically
changing it..

> The header fields required, optional, and not applicable for each method
> are listed in Table 4 and Table 5. The table uses "o" to indicate
> optional, "m" mandatory and "-" for not applicable. 
> 
	"Optional" means that a UAC \MAY include the header in a request,
and a UAS \MAY ignore the header if present in the request. Similarly, an
optional response header implies that a UAS \MAY place the header in a
response, and the UAC \MAY ignore the header if present in a response it
receives. 

	"Mandatory" means the UAC \MUST include the header in a request, and
a UAS \MUST understand the header if present in a request it receives.
Similarly, a mandatory response header implies that a UAS \MUST place the
header in a response, and the UAC \MUST understand the header if present in
a response it receives. 

> "Not applicable" means the UAC \SHOULDNOT include the header in a request,
> and a UAS \SHOULD ignore the header if present in a request it receives.
> Similarly, a not applicable response header implies that a UAS \SHOULDNOT
> place the header in a response, and the UAC \SHOULD ignore the header if
> present in a response it receives. 
> 
> "m*" means the UAC \SHOULD include the header in a request, and a UAS
> \MUST process requests without that header field. Similarly, a mandatory
> response header implies that a UAS \SHOULD place the header in a response,
> and the UAC \MUST process responses without that header field. 
> 
Editorial note: Not sure about the phrasing of the receiver requirement in
the above paragraph, but there is definitely a receiver requirement needed.

> A "*" indicates that the header fields are needed only if message body is
> not
> empty. See sections 6.18, 6.19 and 8 for details.
> 
Keith

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

> ----------
> From: 	Jonathan Rosenberg[SMTP:[email-masked]]
> Sent: 	31 October 2000 16:58
> To: 	'james jack'; [email-masked]
> Subject: 	RE: [SIP] discussion
> 
> These are ignored. Thats what optional means, although this probably needs
> to be clarified. The text in Section 6 currently reads:
> 
> The header fields required, optional and not applicable for each method
> are
> listed in Table 4 and Table 5.
> The table uses "o" to indicate optional, "m" mandatory and "-" for not
> applicable. "m*" indicates a header
> that SHOULD be sent, but servers need to be prepared to receive requests
> without that header field. A "*"
> indicates that the header fields are needed only if message body is not
> empty. See sections 6.18, 6.19 and 8
> for details.
> 
> 
> I would suggest:
> 
> The header fields required, optional, and not applicable for each method
> are
> listed in Table 4 and Table 5. The table uses "o" to indicate optional,
> "m"
> mandatory and "-" for not applicable. Optional means that a UAC \MAY
> include
> the header in a request, and a UAS \MAY ignore the header if present in
> the
> request. Similarly, an optional response header implies that a UAS \MAY
> place the header in a response, and the UAC \MAY ignore the header if
> present in a response it receives. A mandatory request header means the
> header \MUST be present in a request, and \MUST be understood by the UAS
> receiving the request. A mandatory response header means the header \MUST
> be
> present in the response, and the header \MUST be understood by the UAS
> processing the response. "Not applicable" for request headers means the
> header \SHOULDNOT be present in a request. If one is placed in a request,
> it
> \SHOULD be ignored by the UAS receiving the request. Similarly, a header
> "not applicable" for a response means the UAS \SHOULDNOT place the header
> in
> the response, and the UAC \SHOULD ignore the header in the response. "m*"
> indicates a header
> that SHOULD be sent, but servers need to be prepared to receive requests
> without that header field. A "*"
> indicates that the header fields are needed only if message body is not
> empty. See sections 6.18, 6.19 and 8
> for details.
> 
> 
> 
> Sound OK?
> 
> 
> 
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>  
> 
> > -----Original Message-----
> > From: james jack [mailto:[email-masked]]
> > Sent: Tuesday, October 31, 2000 7:02 AM
> > To: [email-masked]
> > Subject: [SIP] discussion
> > 
> > 
> > Dear All:
> >       I have one question to ask, If an request
> > contains 
> > One header that is not applicable according to
> > RFC2543bis
> > 02, for example, in REGISTER request, there appear
> > Alert-info, Priority,
> > how to cope with this request, 400 response code or
> > discard this header
> > and continue to process? 
> >       Could anyone give me some advice or suggestion
> > for processing such stuation? 
> >      Best regards!
> >                                Yours:james
> >   
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Messenger - Talk while you surf!  It's FREE.
> > http://im.yahoo.com/
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 7 Nov 2000 11:33:46 -0000

> Some minor tweaks to the original proposal, with the aim of
> aligning all the text into a common format, and ensuring that
> we have a clearly specified set of sender and receiver
> requirements, and not with any aim of technically changing it..
>

Immediately, Require springs to mind; surely a UAS MUST take notice
of Require?  What about Record-Route, or Accept?  While it seems
appropriate to identify UAC behaviour with Requests, and UAS
behaviour with Responses, I am not sure that it can be taken much
further except on a header-by-header basis.

> header in a response, and the UAC \MUST understand the header if

[...]

 - Jo.
--
  Jo Hornsby; IT Professional         --       mailto:[email-masked]
 Ubiquity Software Corporation        --         http://www.ubiquity.net/
                                Hi, Chris! &:)