Subject: Re: [Sipping] Config Framework: extending HTTP?

From: Daniel Petrie <[email-masked]>
Date: Thu, 5 Oct 2006 09:27:25 -0700 (PDT)

Hi Lisa:
Thanks for the comments.  Yes the event header is not explained well in
the config. draft.  The Event header is an invention of RFC 3265 where
it is much better explained.  The config. draft assumes knowledge of
3265 and extends the Event header by adding new parameters.  Though the
Event header in SIP is more general than is needed for the HTTP
message, almost everything that is contained in the SIP Event header
for the config usage, is need in the HTTP message.  It just seemed like
a good reuse of syntax and symantics for it to be the the same in HTTP
and SIP.  
The meaning of the Event header is basically the same as in 3265.  

It is an HTTP request for state data for the given event (or state data
type).  I do not really want to bite off the burden of defining an HTTP
means of doing 3265.  The usage define here should be specific to the
config. usage.  However I think the usage is clean enough such that
someone could define a means of using HTTP to retrieve SIP events and
the usage in the config. draft would be fairly compatible.

I will try to clean up the text in the draft a bit and incorporate some
of the motivation and explaination from this thread.

Cheers,
Dan

--- Lisa Dusseault <[email-masked]> wrote:

> Yes, new HTTP headers now need to be registered.  Good catch.
> 
> For review by "The HTTP community" we can of course send to the HTTP 
> 
> list from the WG long ago -- it's actually still sporadically  
> active.  There's also the Apps review team which is happy to do early
>  
> review of documents from other areas, that may benefit from HTTP,  
> messaging, XML or i18n expertise.
> 
> Dan, I glanced at your config-framework document and found it very  
> hard to figure out what the Event header is for.  It seems to be a  
> bag for a bunch of metadata.  Organization and naming -- possibly a  
> name that is less generic, possibly organization into more than one  
> clearly-defined header -- should be considered at some point.  The  
> way you explain in email below is slightly better than the draft, but
>  
> "to carry vendor, model, version" doesn't sound like it matches up  
> with the name "Event"  for the header.
> 
> Lisa
> 
> On Oct 4, 2006, at 7:58 AM, Henning Schulzrinne wrote:
> 
> > I will note that the RELO draft of mine in GEOPRIV makes exactly  
> > the same addition to HTTP. Maybe you can steal the text...
> >
> > I believe there's clearly a need for a mechanism of this nature.
> >
> > Daniel Petrie wrote:
> >> The config draft proposes using an Event header for the
> >> profile HTTP GET to carry the Event parameters such as
> >> vendor, model, version.  The data in these parameters are
> >> necessary, mostly in the boot strapping from HTTP situation
> >> so that the profile delivery server can provide the correct
> >> profile data.
> >> I checked with Lisa in Montreal when Adam brought this issue
> >> up and she said it was reasonable for applications to add
> >> new HTTP headers.  I announced this at the WG meeting.  Sorry,
> >> I should have propagated it to the list as well.  I have cleaned
> up
> >> the IANA section for both HTTP and SIP in the config. draft.
> >> As for the config draft status, I think that it is ready to submit
>  
> >> for
> >> WG LC.  It is checked in and ready to submit.  I just need to
> confirm
> >> that I have resolved two of the issues that were brought up on the
>  
> >> list
> >> at Montreal.
> >> Cheers,
> >> Dan
> >> --- Cullen Jennings <[email-masked]> wrote:
> >>> Ok - I'm clueless. I'm missing what you guys are talking about
> here.
> >>> Can you clue me in? Also, any ETA on update of this critical
> draft?
> >>>
> >>>
> >>> On Jul 8, 2006, at 11:21 PM, Dan Petrie wrote:
> >>>
> >>>> Ok you caught me.  I did not think the HTTP police
> >>>> were watching.
> >>>>
> >>>> What is your recommendation?  Shall we use a form
> >>>> variable called Event?
> >>>>
> >>>> Cheers,
> >>>> Dan
> >>>>
> >>>> --- Adam Roach <[email-masked]> wrote:
> >>>>
> >>>>> There is a procedure described in the current config framework
> >>>>> document
> >>>>>
> >>>> (http://www.ietf.org/internet-drafts/draft-ietf-sipping-config- 
> 
> >>>> framework-08.txt),
> >>>>> starting on page 26, which effectively allows the device to
> >>> bootstrap
> >>>>> configuration using an HTTPS URI. In this procedure, the client
> >>>>> includes
> >>>>> the RFC3265 "Event" header field, so as to communicate a set of
> >>>>> relatively critical parameters.
> >>>>>
> >>>>> At the very least, I think this requires some discussion in the
> >>> IANA
> >>>>> section to add this header's use in HTTP (the proper registry,
> I
> >>>>> believe, is
> >>>>>
> >>>> http://www.iana.org/assignments/message-headers/message-header- 
> 
> >>>> index.html,
> >>>>> defined in RFC3864).
> >>>>>
> >>>>> I would also think that the general usage of an HTTP header in
> >>> this
> >>>>> way
> >>>>> should probably be run by the http community.
> >>>>>
> >>>>> Sorry if this has been brought up in the past, but I don't
> recall
> >>>>> discussions along these lines, and a quick search through the
> >>> mailing
> >>>>> list archives didn't turn anything up.
> >>>>>
> >>>>> /a
> >> SIPez LLC  SIP VoIP, IM and Presence Consulting  http:/ 
> >> www.sipez.com  tel: +1 (617) 273-4000
> >> _______________________________________________
> >> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP
> >> Use [email-masked] for questions on current sip
> >> Use [email-masked] for new developments of core SIP
> 
> 

SIPez LLC  
SIP VoIP, IM and Presence Consulting  
http:/www.sipez.com  
tel: +1 (617) 273-4000

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