Subject: [sipcore] Part2: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Document structure

From: Mary Barnes <[email-masked]>
Date: Thu, 17 Feb 2011 12:32:32 -0600

Hi John,

See comments inline below [MB2].

Thanks,
Mary.

> ------ Earlier part snipped - see Part 1: Including all hi-entries in
> responses
>

> >
> >       General comment:
> >       I found it really hard to understand how all the
> > different procedures in sections 6, 7 and 8 fitted together,
> > and I tried to analyse what exactly is going on. I came to
> > the conclusion that, to a first approximation, we are trying
> > to specify the following:
> >
> >       1. Procedures for receiving a request
> >       - Cache the sequence of entries received.
> >       - If no entry or if last entry does not match
> > Request-URI, create one and add it to the cache.
> >
> >       2. Procedures for sending a request
> >       - Include all cached entries (if any).
> >       - Also include an entry reflecting the Request-URI of
> > the sent request (not quite sure if this should go in the
> > cache at this stage).
> >       - In case of recursing, include in that new entry
> > parameters from the Contact header field of the 3XX response.
> >
> >       3. Procedures for receiving a response (other than 100)
> >       - Add to the cache any entries in the response not
> > already in the cache.
> >
> >       4. Procedures for sending a response (other than 100)
> >       - Include all cached entries.
> >
> >       I am sure this is an over simplification. It doesn't
> > take account of the presence of the option tag in Supported
> > (influences response behaviour), privacy considerations,
> > populating the index, etc.. Also there are clearly some
> > issues concerning exactly what a proxy includes from previous
> > targetings when it retargets, what goes in provisional
> > responses, and so on (impacted by the comments above, no
> > doubt). However, I can't help feeling there might be a much
> > simpler way of documenting all this.
> >
> >
> > [MB] At this point, having worked on this document way too
> > long, it's really hard for me to see how to make it more
> > clear.  It really is fairly simple. The intent of 7.1.1 was
> > to define the steps similar to your simplified summary above.
> [JRE] That is not how I see it. 7.1 only deals with requests, not
> responses, and 7.1 only deals with proxy/intermediary, not UAC, UAS,
> redirect server. I was trying to pull all these together into one set of
> procedures that is common to all (except obviously steps relating to
> receiving a request and sending a response will not apply to a UAC and steps
> relating to sending a request and receiving a response will not apply to a
> UAS or redirect server (or a proxy that rejects). In other words, I was
> trying to pull together sections 6, 7 and 8 into a single section covering
> everything. This is because procedures for receiving request, for example,
> are similar no matter which entity is involved.
>

[MB2] Correct 7.1 only deals with requests, but that section does comprise
your items 1 and 2.
Per my response below, it was a conscious decision to split the processing
as I noted has been done with other RFCs.    And, there are slight
differences for the processing for receipt of requests by a UAS versus an
intermediary and responses at a UAC versus and intermediary.  I do not see
that there is a significant amount of redundant text as is.  We could
rewrite certainly (yet again) if there is consensus that it is not possible
to understand normative behavior from this version. I can see value in
adding an overview section that summarizes the overall processing (per the
end of your email) and then we can leave 6, 7 and 8 as is.  We can also
consider that previous feedback was that we need more of an overview of
processing, which is why some additional text was added to section     in a
previous update. [/MB2]

>
> > As far as handling the privacy, that applies to the entirety
> > of the hi-entries being included in an outgoing request per
> > the rules that we tried to highlight in the updated privacy
> > section.  The mechanism by which the index is calculated is
> > referenced in the appropriate sections and included all in
> > one place.  I could see that we could spread out how all the
> > parameters are determined directly in the processing flow and
> > within the discussion of the specific cases, however, that
> > isn't nearly as modular IMHO. We did have some of it
> > previously, but we also had inconsistencies by doing so (and
> > overuse of normative statements at least as I interpreted WG
> > feedback).
> [JRE] I am quite happy with common procedures like privacy, Reason header
> field and indexing to be kept separate, as we already have in section 9. My
> comments referred to sections 6, 7 and 8, and even if we decide to
> restructure these, we can still refer out to section 9 for the common bits.
>
> > IMHO  the current form is easier from an
> > implementors perspective. And, the form of this document is
> > not dramatically unlike other RFCs, including RFC 3261
> > although the ABNF is earlier in the document in 4244bis.
> > 4244bis follows the model of describing processing for each
> > of the functional entities and then has sections that
> > describe the handling for each protocol element.  From a
> > quick glance RFC 4028 (Session timer) and  RFC 3325
> > (P-Asserted-Identity) have separate sections for Proxy and UA
> > behaviors, as well although the ABNF is later (but again we
> > got feedback that it should be earlier. It's really a chicken
> > egg thing in my opinion as to whether you see the protocol
> > elements first and whether the normative behavior for each
> > parameter is separate from the processing flow for the SIP
> > entities and whether the latter is separated - i.e., we could
> > have a handling the request section that includes the UAC and
> > SIP intermediary behavior and then have a response section
> > that includes SIP intermediary and UAS processing.  But,
> > again I personally feel that have the sections separate is
> > more useful for implementors that are in many cases
> > developing code for only a single functional entity.  [/MB]
> [JRE] Putting aside for the moment the question of whether to restructure
> sections 6, 7 and 8, I would like to try to refine the simplified model I
> proposed to get a common understanding of what we are trying to achieve. A
> commonly understood model would help me to review the existing text to
> ensure that it is consistent with the model. At present I am finding it
> difficult to understand the text. Perhaps that is my fault, not having put
> enough time into it, but I would appreciate assistance from the WG in trying
> to get a better understanding. So here again is the model as I see it
> (slightly changed from before):
>
>
> 1. Procedures for receiving a request
> - Cache the sequence of entries received.
> - If no entry or if last entry does not match Request-URI, create one and
> add it to the cache.
>
> 2. Procedures for sending a request
> - Generate an additional entry reflecting the Request-URI of the sent
> request, and add this to the cache.
> - In case of recursing, include in that new entry parameters from the
> Contact header field of the 3XX response.
> - Include all cached entries.
>
> 3. Procedures for receiving a response (other than 100)
> - Add to the cache any entries in the response not already in the cache.
> - In the case of a 3xx/4xx/5xx/6xx response, add a Reason header field to
> the cached entry that was generated for the corresponding request.
>
> 4. Procedures for sending a response (other than 100)
> - Include all cached entries.
>
> All of the above subject to common rules relating to privacy, histinfo
> option tag, and indices.
>
[MB2] Per my comment above, I also think it could add value to have an
overview of the processing, but I still think it's better to have separate
UAC, UAS, etc. processing per my comments above.  My one fear, however, is
that this would take the document back to the point that folks are saying
there is too much redundant text, the doc is too big, etc. We do explain the
structure of the doc in section 5 in an attempt to set the appropriate
context for folks in reading the sections. And, we did previously add a bit
more detail on the overall flow of handling the header.  Thus, I think there
might be a middle ground and we beef up the text in section 5 or we update
section 6 to include sub-sections for what is now 6, 7 & 8 and include an
overview of operation in body of section 6.    [/MB2]

> John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Feb 2011 22:26:58 +0100

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 17 February 2011 18:33
> To: Elwell, John
> Cc: SIPCORE
> Subject: Part2: Some comments on 
> draft-ietf-sipcore-rfc4244bis-03.txt - Document structure
> 
> Hi John,
> 
> 	------ Earlier part snipped - see Part 1: Including all 
> hi-entries in responses
> 
> 
>  
> 
> 	>
> 	>       General comment:
> 	[JRE] That is not how I see it. 7.1 only deals with 
> requests, not responses, and 7.1 only deals with 
> proxy/intermediary, not UAC, UAS, redirect server. I was 
> trying to pull all these together into one set of procedures 
> that is common to all (except obviously steps relating to 
> receiving a request and sending a response will not apply to 
> a UAC and steps relating to sending a request and receiving a 
> response will not apply to a UAS or redirect server (or a 
> proxy that rejects). In other words, I was trying to pull 
> together sections 6, 7 and 8 into a single section covering 
> everything. This is because procedures for receiving request, 
> for example, are similar no matter which entity is involved.
> 	
> 
> 
> [MB2] Correct 7.1 only deals with requests, but that section 
> does comprise your items 1 and 2. 
> Per my response below, it was a conscious decision to split 
> the processing as I noted has been done with other RFCs.    
> And, there are slight differences for the processing for 
> receipt of requests by a UAS versus an intermediary and 
> responses at a UAC versus and intermediary.  I do not see 
> that there is a significant amount of redundant text as is.  
> We could rewrite certainly (yet again) if there is consensus 
> that it is not possible to understand normative behavior from 
> this version. I can see value in adding an overview section 
> that summarizes the overall processing (per the end of your 
> email) and then we can leave 6, 7 and 8 as is.  We can also 
> consider that previous feedback was that we need more of an 
> overview of processing, which is why some additional text was 
> added to section     in a previous update. [/MB2]
> 
> 
> 	[JRE] I am quite happy with common procedures like 
> privacy, Reason header field and indexing to be kept 
> separate, as we already have in section 9. My comments 
> referred to sections 6, 7 and 8, and even if we decide to 
> 	[JRE] Putting aside for the moment the question of 
> whether to restructure sections 6, 7 and 8, I would like to 
> try to refine the simplified model I proposed to get a common 
> understanding of what we are trying to achieve. A commonly 
> understood model would help me to review the existing text to 
> ensure that it is consistent with the model. At present I am 
> finding it difficult to understand the text. Perhaps that is 
> my fault, not having put enough time into it, but I would 
> appreciate assistance from the WG in trying to get a better 
> understanding. So here again is the model as I see it 
> 	- Generate an additional entry reflecting the 
> Request-URI of the sent request, and add this to the cache.
> 	
> 	- In the case of a 3xx/4xx/5xx/6xx response, add a 
> Reason header field to the cached entry that was generated 
> for the corresponding request.
> 	
> 
> 	All of the above subject to common rules relating to 
> privacy, histinfo option tag, and indices.
> 	
> 
> [MB2] Per my comment above, I also think it could add value 
> to have an overview of the processing, but I still think it's 
> better to have separate UAC, UAS, etc. processing per my 
> comments above.  My one fear, however, is that this would 
> take the document back to the point that folks are saying 
> there is too much redundant text, the doc is too big, etc. We 
> do explain the structure of the doc in section 5 in an 
> attempt to set the appropriate context for folks in reading 
> the sections. And, we did previously add a bit more detail on 
> the overall flow of handling the header.  Thus, I think there 
> might be a middle ground and we beef up the text in section 5 
> or we update section 6 to include sub-sections for what is 
> now 6, 7 & 8 and include an overview of operation in body of 
> section 6.    [/MB2] 
[JRE] The simple model I am trying to capture by email is just for understanding. When I fully understand what we are trying to achieve technically (I thought I understood it months ago during the previous review, but clearly not) I can then try to determine whether there are holes that need fixing in the current text and whether these just require patches or something more substantial. I will start a new thread on the model.

John