Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

[Cullen Jennings <[e-mail]>]

Privacy issue: There is no way to know that the next downstream proxy support the processing required by the privacy header. 

What's this for: The most concrete use is making sure a call arriving at a voice mail servers goes to the correct mailbox. However, the draft is woefully underspecified to be able to implement this from the draft. This draft specifies a bunch of data that can get dumped in a bag, but to allow interoperable implementation, it needs to say how one could use that data for some actually feature. 

As a coauthor of 4244, I agree this draft is better than 4244 but I don't think it is ready to publish.Given what we have learned about 4244 since it was published, I would support 4244 being changed to historic. 

Does it work? Consider text such as  

       Note, this would be
       the original AoR if all the entities involved support the
       History-info header field and there is absence of an "mp" header
       field parameter prior to the "rc" header field parameter in the
       hi-target-param in the History-info header field.  However, there
       is no guarantee that all entities will support History-Info, thus
       the hi-entry that matches the value of the "rc" parameter of the
       first hi-entry with an "rc" parameter in the hi-target-param
       within the domain associated with the target URI at the
       destination is more likely to be useful.

This amounts to you might some information you want at X but then again you might not. The whole draft is like this - it's pretty hard to imagine this will reliably work for nearly any purpose I can think of given the limitations of the draft. 

Backwards Compatibly - yes the syntax is backwards compatible but no effort has been put into consider what would happen if some elements in the network were doing 4244 and some where doing 4244bis.

Implementations: I'd like to know about implementations that were going to use this data. And by use, I don't mean write to the history header but instead ones that are going to read from it and use the information for some purpose. 

Does not meet requirements. As far as I can tell, the draft does not meet the requirements outline in section A.1 of the draft. 






On Jun 5, 2011, at 17:33 , Paul Kyzivat wrote:

> [as co-chair]
> 
> The current editor of draft-ietf-sipcore-rfc4244bis believes that the document has no remaining technical issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Sunday, June 19.
> 
> The latest version of the document can be retrieved here:
> 
> http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis
> 
> Any comments on the document should be sent to the SIPCORE mailing list.
> 
>     Thanks,
>     Paul
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html