Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 10 Jul 2006 15:13:41 +0100

Getting back to the Warning issue:

Inline below

Keith

> -----Original Message-----
> From: Scott Lawrence [mailto:[email-masked]]
> Sent: 08 June 2006 19:04
> To: Drage, Keith (Keith)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Sip] I-D
> ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt
> 
> 
> On Thu, 2006-06-08 at 18:29 +0100, Drage, Keith (Keith) wrote:
<snipped>
> > > > 2)	Section 2.2 and elsewhere, I am not convinced that the 
> > > use of the
> > > > Warning header is consistent with RFC 3261. The clear 
> implication of
> > > > RFC 3261 is that Warning headers relate only to the session
> > > > description contained in the request.
> > > 
> > > It didn't seem worth the trouble to define a new header, 
> or to require
> > > some multipart body just to identify the last server - I'm open to
> > > suggestions.  It seems a valuable part of the diagnostic 
> information.
> > > 
> > Well if we continue to use the Warning header, this would be another
> > update of RFC 3261 to extend the usage of Warning, at least in my
> > understanding, and that would need to be defined.
> 
> RFC 3261, section 20.43 Warning says:
> 
>            The Warning header field is used to carry 
> additional information
>            about the status of a response.
> and
>            The currently-defined "warn-code"s are listed below, with a
>            recommended warn-text in English and a description 
> of their meaning.
>            These warnings describe failures induced by the 
> session description.
>            The first digit of warning codes beginning with 
> "3" indicates
>            warnings specific to SIP.  Warnings 300 through 
> 329 are reserved for
>            indicating problems with keywords in the session 
> description, 330
>            through 339 are warnings related to basic network 
> services requested
>            in the session description, 370 through 379 are 
> warnings related to
>            quantitative QoS parameters requested in the 
> session description, and
>            390 through 399 are miscellaneous warnings that do 
> not fall into one
>            of the above categories.
> 
> it seems to me that this already explicitly allows for usages 
> other than
> session description errors by allowing "miscellaneous warnings that do
> not fall into one of the above categories". 
> 
> Arguably, this could call for actually registering a code in the 39x
> range; if the WG thinks that's better, I can add an IANA 
> Considerations
> section to do that.
> 
The text you are quoting is I agree vague, but implies that 390 through 399 vcould be so used.

However if continue on in the text of the section you are reading:

   Additional "warn-code"s can be defined through IANA, as defined in
   Section 27.2.

and you go to the IANA registration section in 27.2:

   This specification establishes the Warn-codes sub-registry under
   http://www.iana.org/assignments/sip-parameters and initiates its
   population with the warn-codes listed in Section 20.43.  Additional
   warn-codes are registered by RFC publication.

Rosenberg, et. al.          Standards Track                   [Page 252]

RFC 3261            SIP: Session Initiation Protocol           June 2002

   The descriptive text for the table of warn-codes is:

   Warning codes provide information supplemental to the status code in
   SIP response messages when the failure of the transaction results
   from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.

   The "warn-code" consists of three digits.  A first digit of "3"
   indicates warnings specific to SIP.  Until a future specification
   describes uses of warn-codes other than 3xx, only 3xx warn-codes may
   be registered.

   Warnings 300 through 329 are reserved for indicating problems with
   keywords in the session description, 330 through 339 are warnings
   related to basic network services requested in the session
   description, 370 through 379 are warnings related to quantitative QoS
   parameters requested in the session description, and 390 through 399
   are miscellaneous warnings that do not fall into one of the above
   categories.

I believe this text is clear in requiring IANA to register codes that apply only to SDP errors.

The text is reproduced on the IANA registry page concerned.

Now whether we should change this or not I will leave open to discussion, but that is what it says at the moment.

> > Out of interest, what harm would occur by adding it to the Server
> > header? Alternatively, could the Contact header be allowed in a 483
> > response mean this?
> 
> The Server header is defined as providing information about 
> the software
> of the UAS, and as such the syntax doesn't allow for a field that is
> identifiably the address or host name.
> 
> I'm concerned that including a Contact is more likely to confuse
> implementations that don't expect to see them in an error response
> (especially since it is often going to be coming from a proxy).
> 

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

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 10 Jul 2006 17:05:23 -0400

> Now whether we should change this or not I will leave open to discussion, but that is what it says at the moment.

Fair enough.

I've explained why I think the Server and Contact headers are not good
for identifying the responding server, and I think that the value of
identifying the responding server is clear.  
 
What does the group think is better:

- define a new mechanism 
- expanding the usage of Warning

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

---

From: Robert Sparks <[email-masked]>
Date: Mon, 10 Jul 2006 17:59:02 -0400

On Jul 10, 2006, at 5:05 PM, Scott Lawrence wrote:

> ...
>> Now whether we should change this or not I will leave open to  
>> discussion, but that is what it says at the moment.
>
> Fair enough.
>

I don't feel strongly, but if we allow the scope to creep to other  
response conditions, then I suspect
we'll be better off with a new mechanism and propose that carrying  
that data (and any other meta-data
we might discover useful) in the body.

RjS