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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Jun 2006 18:29:57 +0100

See below.

I've retained only the points inviting further discussion.

regards

Keith

> -----Original Message-----
> From: Scott Lawrence [mailto:[email-masked]]
> Sent: 08 June 2006 16:44
> 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 Wed, 2006-06-07 at 11:39 +0100, Drage, Keith (Keith) wrote:
> > I worked through this document and identified the following 
> points for consideration.
> 
> Thanks.
> 
> > Technical
> > ---------
> > 
> > 1)	Section 2.2, final indented paragraph. Firstly, can we emphasise
> > that this applies to any method, e.g. by inserting the 
> words: "Any 483
> > response, to any method, SHOULD..." Secondly, if we are going to use
> > SHOULD here, can we insert some informative text relating 
> to why it is
> > only a SHOULD and not a MUST, and therefore giving the reader the
> > understanding of why it does not always apply.
> 
> Why do you think that the method needs to be mentioned?  I 
> don't see any
> ambiguity in "any 483 response".
> 
Because I read the document twice before I came to the conclusion that the "any" meant "any method" as well as "any point in time that you receive". As all the examples in the document relate to the INVITE request, it seemed to me useful to emphasise that it was more comprehensive. In other words, it seemed to me that there was scope for sloppy reader to get it wrong.

> > 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.

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?

> > NITS
> > ----
> > 
> > a)	Wherever we indicate "483 error response" in the text, can we
> > follow the style of RFC 3261 and change it to "483 (Too Many Hops)
> > response code"?
> 
> I started to make that change, and it seemed to me that this 
> got pretty
> repetitive if done everywhere.  Given that the entire draft is on this
> one response, I'm not sure this actually improves the clarity.
> 
The clarity improvement is I agree not substantial, but I find that it helps if multiple documents present the same information in the same style.

> -- 
> 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/

_______________________________________________
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

_______________________________________________
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: Thu, 08 Jun 2006 14:03:53 -0400

On Thu, 2006-06-08 at 18:29 +0100, Drage, Keith (Keith) wrote:
> Because I read the document twice before I came to the conclusion that
> the "any" meant "any method" as well as "any point in time that you
> receive". As all the examples in the document relate to the INVITE
> request, it seemed to me useful to emphasise that it was more
> comprehensive. In other words, it seemed to me that there was scope
> for sloppy reader to get it wrong.

Hmmm... well, how about changing:

        Any 483 response SHOULD be constructed with ...
to
        Whenever a UAS constructs a 483 (Too Many Hops) response to any
        request whose Max-Forwards header field value has reached zero,
        the response SHOULD be constructed with ...

This reminds me that I didn't address the issue of using 'UAC' and 'UAS'
where the current text uses 'sender' and 'receiver'; I'll look at that
elsewhere too...

> 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.

> 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).

> The clarity improvement is I agree not substantial, but I find that it
> helps if multiple documents present the same information in the same
> style.

It probably should be done that way in at least some places (as in my
suggested text above), but I think it's actually detrimental to do it
where the code appears 3 times in the same paragraph...

-- 
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: "Dale R. Worley" <[email-masked]>
Date: Thu, 15 Jun 2006 09:02:28 -0400

> range; if the WG thinks that's better, I can add an IANA Considerations

That seems like a good idea. Since there is hope that an automaton
(traceroute-like program) will be able to interpret the responses, a
known warning code would be a label that the message/sipfrag body part
is one of these diagnostic messages.

Dale