Re: [6lowapp] BOF proposal: update

[Carsten Bormann <[e-mail]>]

David,

thanks your for your input.

I'll leave the discussion of Smart Energy timelines to Don for now.
Let me just point out that in other places where we had to work with  
organizations with "impossible" timelines, we were able to do the  
finishing in parallel.  E.g., consider the way ISA100 has now  
published ISA100.11a, while we are in parallel in the process of  
preparing for WGLC of 6lowpan-hc.
For 6lowapp, the organizations making use of our results may not have  
to sit on their hands till Q3/Q4 2010.
And we *do* need some time for that finishing.
(I'm open to suggestions we can be faster than that, but the  
milestones sound right to my gut feeling.)

> Also, it might be fair to add HomePlug to the Smart Energy v2.0 list
> as that group has also
> been involved.

It actually does say on the agenda; we neglected to put that up in the  
charter outline text as well.  Fixed in the current working draft.

>> The goal of 6lowapp is to produce application protocol and
>> application commissioning solutions suitable for providing us the web
>> for resource constrained devices
>
> The initial paragraph discusses "application protocols" for the
> "Wireless Embedded Internet", while other sections
> discuss the "embedded web" and "web for resource constrained devices".
> Is there a difference?

Wireless Embedded Internet is a more general term, just as Internet is  
more general than Web (at least if you count the networked  
applications with the networking itself).
The proposal is indeed to use the lessons of the Web to empower the  
Wireless Embedded Internet.
We can work on reducing the number of terms here.

>> This working group will not work on new content formats
>> or encodings, nor the compression or adaptation of HTTP. (to be  
>> expanded)
>
> I realise there is a comment that this needs "to be expanded", so I
> apologise for jumping
> the gun.  If the aim is to build the "embedded web" and not adapt
> HTTP, does this suggest
> that the draft submitted by Brian Frank (Chopan) is outside the scope
> of the working group?

Indeed, this is a little terse.  I think Brian's work is very good  
input.
The point here is that simply compressing HTTP (as in GZIP or  
something slightly better) does not cut it -- if the embedded node  
still has to process all the complexity of HTTP that is a problem.  If  
your definition of "compressing" includes coming up with a simplified  
subset that still solves the important problems, the wording of this  
exclusion may sound wrong.

> I'd also like to ask the rational for discarding the concept of new
> content formats or encodings?
> Assuming that a new format or encoding has benefits as defined by the
> "Problem Statement and
> Objectives", shouldn't it be within the scope to review and debate the
> merits of such encodings?

I think the 6lowapp application protocol needs to be format agnostic,  
just as MIME types have made HTTP format agnostic.

Re standardizing another format/encoding:
I have heard a lot of hesitation going into that from individuals  
interested in this work.
The problem is not that there are too few formats.
The issue is what are the right properties of the formats for  
different areas of application.
Yes, some people like EXI in this regard, but it may not be our job to  
choose -- maybe just to elucidate.

> To be open and clear to everyone on the list, I plan on submitting a
> draft which incorporates what
> many will consider a new encoding.  The issue of data formats is also
> mentioned here:
>
>> Data formats will be considered
>> in the working group as general requirements and considerations in  
>> the
>> other technical work, but no new standardization is needed.

I still think your draft may be good input to the requirements work  
(the "problem statement and objectives" deliverable).
But we cannot take on standardization (i.e., a fourth deliverable) in  
this crowded space unless we have carved out a very specific set of  
requirements not covered yet. We won't manage that in time before the  
BOF, so it would be a mistake to include such a deliverable in the  
charter.

(And thank you for the kind words on how important that new WG will be  
-- I do agree that this is an important point in time to step forward  
and act.)

Gruesse, Carsten