Re: [sipcore] Updated 4244bis and new call flow document

[<[e-mail]>]

Hi Mary and all,

I have some comments on draft-ietf-sipcore-rfc4244bis-01:

1- Regarding the "hit" and "target" parameters, is it really necessary to create both? 
   I mean the "hit" parameter seems almost useless as it has to be removed from the R-URI just 
   after its creation (kept only in the Contact header after a 3xx).
   Why the hi-target couldn't be a single parameter to tag URIs?

2- §4.1 it is said that 
   "The entries SHOULD be evaluated to determine gaps in indices, 
   which could indicate that an entry has been maliciously removed.  
   Either way, an application SHOULD be aware of potentially missing information." 
  If the removed hi-entry is the last destination (leaf) of an unsuccessful route (branch), 
  how is it possible, at the end, to know that there is a missing entry?

3- §5.1.1 At the end of the second sentence, there are 2 right parenthesis.
   §6.3.1 after reference to [RFC3261], there are 2 right square brackets.

4- §6.1 In the rules after the header syntax, the sentence 
   "There MUST be no more than one hi-target parameter." 
   should be completed with "per hi-entry" to be more precise (as it is the case in the previous item).

5- §6.3.2 In the sentence 
	"This is accomplished by adding a new priv-value,
   	history, to the Privacy header [RFC3323] indicating that a specific
   	History-Info header entry can not be forwarded outside the domain."
   It should be better to complete with : To do this, the Privacy header with the priv-value history is 
   escaped in the hi-entry corresponding to the concerned URI.

6- §7: 
	"For example, an Automatic Call Distribution (ACD)/Call center application
   	that utilizes the entry prior to the first History-Info entry with an
   	hi-target value of "mp", ..."
   Do you mean the entry with the index that matches the first History-Info entry with an hi-target value of "mp"? (instead of the prior)

7- Appendix B.2 and B.3: what is the "p=x" in the URI?

Cheers,
Marianne 

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Mary Barnes
Envoyé : jeudi 1 juillet 2010 21:31
À : SIPCORE
Objet : Re: [sipcore] Updated 4244bis and new call flow document

Hi folks,

I have not seen any responses to this email. So, either folks don't see any issues with the documents and 4244bis is ready for WGLC or folks have not reviewed the documents.  I'm happy to assume the former, however, it would be good for folks that have read the docs to post a note on the mailing list as to whether they think  4244bis is ready for WGLC.  And, if not, please detail your concerns, so that we can determine whether they warrant discussion in Maastricht.

Also, opinions on how/where to progress the call flow document would be welcome.  I personally do not think it's worthwhile to pursue this in DISPATCH, but it's not clear to me whether informational docs like this are under the purview of the SIPCORE charter.  Since BLISS is trying to close down, it is also not appropriate to pursue the work there.

Thanks,
Mary.

On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes <[e-mail]> wrote:
> Hi folks,
>
> The 4244bis draft has been updated and a separate call flow document 
> created per the earlier summary of proposed changes:
> http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html
>
> http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt
> http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.tx
> t
>
> There are  two voicemail examples in the new call flow document.  The 
> 4244bis has 3 call flows - the basic sequential forking and two 
> privacy examples. All the rest are now in the call flow document.
>
> The other changes we made were updates to the UAC, UAS and application 
> considerations section - adding additional text as to how the UAC and 
> UAS process hi-entries (including related to responses).  The 
> application considerations section now describes how the tags can be 
> used to derive specific information and the past guidelines were 
> removed since 4244bis has much definitive guidance on the normative 
> aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via 
> anonymization rather than removing entries, etc.) as summarized in 
> Section 11.
>
> Please review and provide any additional comments. We believe that 
> 4244bis is pretty much ready to go. We can fine tune the details in 
> the call flows and should be able to get that ready very soon, as 
> well.  Let us know if you see additional use cases you would like to 
> add.
>
> Thanks,
> Mary et al
>
_______________________________________________
sipcore mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sipcore