Subject: Notes from Oct 23 IETF/W3C coordination call

From: Lisa Dusseault <[email-masked]>
Date: Tue, 6 Nov 2007 15:08:19 -0800

These notes are reconstructed from the Jabber transcripts.  Thanks  
Thomas and Mark for taking the jabber notes.

Please send comments by Nov 13 so I can get these out (and by the  
way, what's the process for that?)

Lisa

-----

Agenda (after bashing on call):

1.  Work done by Content Transformation Task Force in the Mobile Web  
Initiative Best Practices Working Group -- Dominique Hazael-Massieux  
to join the call -- 15 min
2.  HTTP BIS WG -- Lisa - 5 min
3.  Update on the recently-held W3C Workshop on XML Signature and  
Encryption -- Thomas -- 5 min
4.  Update of WS-Policy and SparQL media type -- 5 min
5. Broader BCP 56 discussion -- everybody - 15 min
6.  Schemes and Protocols -- http://www.w3.org/2001/tag/doc/ 
SchemeProtocols.html -- everybody --  15 min
7.  Agenda for Vancouver IETF -- should these topics be on agendas  
for more discussion? -- Lisa
8.  Content t\ype in HTML 5, link rels

1  Content Transformation

New work in http://www.w3.org/2005/MWI/BPWG/  looking at existing  
technologies
  - based on existing W3C TAG findings
  - working on issues like, how to make sure that a page that is  
already transformed isn't transformed again, how to express  
transformation policy;
  - note recent outcry in UK, because vodafone transcoding proxy  
messed up existing mobile web sites

Discussion of overlap with OPES: since OPES also has transforming  
proxies, in this case HTTP intermediaries.  Does new WG have same  
requirements for disclosure?   IETF/Apps wouldn't force anybody to do  
things this exact way, but there may be lessons to be learned.  For  
example, why has there been no uptake?  Apps ADs aren't aware of  
flaws in the technology, so it may be a socio-economic reason why  
there's no uptake (e.g. the people in a position to implement OPES  
aren't the people who want it)

Announcements requested to go to: apps-review, HTTP WG

2  HTTPbis WG
draft charter: http://lists.w3.org/Archives/Team/w3c-ietf-coord/ 
2007Oct/0001.html
Charter: http://www.ietf.org/html.charters/httpbis-charter.html

Mention of call from semweb community to see what HTTP codes mean.   
The definitions in the standard are sometimes ambiguous and some  
things aren't covered. Can the HTTP WG crisp up those definitions?   
Lisa responded that this kind of effort, crisping up definitions of  
things that have already been standardized, seems to result in years  
worth of bitter arguments (e.g. discussion of what a lock was in  
WebDAV; arguments on resource instances occasioned by Mogul paper  
http://www2002.org/CDROM/refereed/444/).  HTTP has many such  
problems, see similar issues with resource, response, entity.   
Conclusion was that for the semweb community to bring that up in the  
wider community at this point would mean more argument and no  
benefit.  Somebody suggested to produce OWL ontology to do formal  
model and maybe tie to bits over the wire.

Question about charter -- are test suites being developed?  The IETF,  
like W3C, doesn't do compliance outside specs.  The W3C, however,  
keeps test suites.  We think this is important for HTTP to crisp  
things up.  One thing the IETF has done is to produce an I-D or RFC  
that shows torture tests and the like: e.g. request and response  
messages in text form.  Producing the software of a test suite has  
never been a IETF WG deliverable, but it has been done closely with  
WGs.  Similarly, Interop events never done officially by an IETF WG,  
but in concert with one

Patent policy for HTTP?  Tim points out that there's an effective  
royalty-free zone for some standards, it's awkward that HTTP isn't in  
there.   Lisa adds that there's no guarantee that HTTP isn't in the  
royalty-free zone; we just don't know because it was developed with a  
lot of things left unsaid about patent status.  In theory an IETF WG  
can include technology that is patented along with licensing  
assurances.  However, since the WG is revising HTTP without adding  
new inventions, it's unlikely that the WG can add anything that's  
known to be patented.  So HTTP's patent situation will likely remain  
the same: muddy, but no known problems.  We don't see a concrete  
action to take at this point.

NOTE that participants in HTTP WG have to disclose relevant patents  
even if the patents are not new.

3.  XMLsec workshop

Workshop report releasing today: http://www.w3.org/2007/xmlsec/ws/report
Main outcome -- there is some work to be done, both on the crypto  
side and xml side.  IETF involvement is coordination.  Thomas will  
send pointers to SAAG.

Thomas would like IETF feedback on the path forward for selecting  
hash algorithms (e.g., sha-1). Also, what the IETF is (not) doing  
with crypto suite B.  The  TLS WG has been working on revisions to  
the TLS spec for adding cyphersuites, and particularly for hash agility.

4.  WS-Policy and SPARQL media types

Thomas sent e-mail about registering thes, was told to contact IANA;  
they came back and said to talk to the IESG.  Chris agreed to get  
that on the IESG agenda.

5/6.  BCP56, schemes and protocols

Issues about BCP56 have been coming up.  BCP56 was written with the  
experience of abuses of SMTP and other e-mail protocols overloading a  
single port.  It would be bad if use of port 80 required firewalls  
and other intermediaries to get deep into the protocol to be able to  
ensure security or other services. On the other hand, we know that  
BCP56 isn't necessarily the best advice we could give today.

A new port example is IPP:  you can get at IPP resources with HTTP,  
but conventionally they're named ipp:// and not on port 80.  However,  
there are more examples, and more recently, which do not use a new  
scheme nor a new port.  People want new protocols to be easy to  
implemen.  Atompub WG explained issue quite succintly -- want to be  
able to write atompub servers with java servlets or ruby on rails,  
without touching HTTP server engine.

Beyond this formal standards work, there are a huge number of ad-hoc  
protocols.  We can't put all these on separate ports or schemes (or  
can we?)

Another possibility, and perhaps more realistic, is to use separate  
content-types.  The content-type in the client request serves two  
functions, of explaining how to interpret the client request (schema  
and/or language) and also to request a particular service of the  
server.  For example, some certificate retrieval stuff works this  
way, where a MIME type for the request advertises that the request  
contains a detailed query and the response should include one or more  
certificates.

Is separate Content-Types is also a can of worms?  Does it amount to  
content negotiation for format which is mostly considered a failure?   
One doesn't need to see this as negotiation, but rather as an  
indication what the application is.

If most people just use application/xml as the Content-Type, then  
once again we have undifferentiated traffic. Using http scheme, port  
80 and POST of application/xml gives nobody reasonable chance at  
filtering.

Is the content-type registration system easy enough, extensible  
enough?  Is that why they use application/xml?  Chris points out that  
registering in vnd.* is easy, and we also have provisional  
registration.  So why don't inventors of ad-hoc protocols use new  
MIME types?   Is it because they can't be bothered?  Is the issue not  
one of simplifying the process, but one of ownership?  Perhaps when a  
company asks for a registration, they not only publicize their  
intent, they also tie themselves down to one thing (one MIME type,  
scheme, or whatever) and this is the basic reason people make excuses  
-- they just don't want to limit their own actions like this.

Topic: Next meeting

Prefer February: Philippe Le Hegaret will get a date selected.

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 08 Nov 2007 13:07:01 -0500

A comment from someone who was not there -- it would be
valuable to list the attendees of the meeting (particularly
as the notes reference various people by first name only).

WRT process -- W3C will look after posting in their
space, and you can submit them as a "liaison report"
next month when the IAB asks for same.  They will,
eventually, theoretically, appear somewhere on the IAB
website in public and findable fashion.

Leslie.

Lisa Dusseault wrote:
> Please send comments by Nov 13 so I can get these out (and by the way, 
> what's the process for that?)
> 
> Lisa
> 
> ----- 
> 
> Initiative Best Practices Working Group -- Dominique Hazael-Massieux to 
> join the call -- 15 min
> 6.  Schemes and Protocols -- 
> http://www.w3.org/2001/tag/doc/SchemeProtocols.html -- everybody --  15 min
> 7.  Agenda for Vancouver IETF -- should these topics be on agendas for 
> more discussion? -- Lisa
>  - working on issues like, how to make sure that a page that is already 
> transformed isn't transformed again, how to express transformation policy;
>  - note recent outcry in UK, because vodafone transcoding proxy messed 
> up existing mobile web sites
> 
> example, why has there been no uptake?  Apps ADs aren't aware of flaws 
> in the technology, so it may be a socio-economic reason why there's no 
> uptake (e.g. the people in a position to implement OPES aren't the 
> people who want it)
> 
> draft charter: 
> http://lists.w3.org/Archives/Team/w3c-ietf-coord/2007Oct/0001.html
> Mention of call from semweb community to see what HTTP codes mean.  The 
> definitions in the standard are sometimes ambiguous and some things 
> aren't covered. Can the HTTP WG crisp up those definitions?  Lisa 
> responded that this kind of effort, crisping up definitions of things 
> that have already been standardized, seems to result in years worth of 
> bitter arguments (e.g. discussion of what a lock was in WebDAV; 
> arguments on resource instances occasioned by Mogul paper 
> http://www2002.org/CDROM/refereed/444/).  HTTP has many such problems, 
> see similar issues with resource, response, entity.  Conclusion was that 
> for the semweb community to bring that up in the wider community at this 
> point would mean more argument and no benefit.  Somebody suggested to 
> produce OWL ontology to do formal model and maybe tie to bits over the wire.
> 
> like W3C, doesn't do compliance outside specs.  The W3C, however, keeps 
> test suites.  We think this is important for HTTP to crisp things up.  
> One thing the IETF has done is to produce an I-D or RFC that shows 
> torture tests and the like: e.g. request and response messages in text 
> form.  Producing the software of a test suite has never been a IETF WG 
> deliverable, but it has been done closely with WGs.  Similarly, Interop 
> events never done officially by an IETF WG, but in concert with one
> 
> lot of things left unsaid about patent status.  In theory an IETF WG can 
> include technology that is patented along with licensing assurances.  
> However, since the WG is revising HTTP without adding new inventions, 
> it's unlikely that the WG can add anything that's known to be patented.  
> So HTTP's patent situation will likely remain the same: muddy, but no 
> known problems.  We don't see a concrete action to take at this point.
> 
> NOTE that participants in HTTP WG have to disclose relevant patents even 
> if the patents are not new. 
> 
> 3.  XMLsec workshop
> 
> Main outcome -- there is some work to be done, both on the crypto side 
> and xml side.  IETF involvement is coordination.  Thomas will send 
> pointers to SAAG.
> 
> Thomas would like IETF feedback on the path forward for selecting hash 
> algorithms (e.g., sha-1). Also, what the IETF is (not) doing with crypto 
> suite B.  The  TLS WG has been working on revisions to the TLS spec for 
> adding cyphersuites, and particularly for hash agility.
> 
> they came back and said to talk to the IESG.  Chris agreed to get that 
> on the IESG agenda.  
> 
> single port.  It would be bad if use of port 80 required firewalls and 
> other intermediaries to get deep into the protocol to be able to ensure 
> security or other services. On the other hand, we know that BCP56 isn't 
> necessarily the best advice we could give today.   
> 
> implemen.  Atompub WG explained issue quite succintly -- want to be able 
> to write atompub servers with java servlets or ruby on rails, without 
> touching HTTP server engine.
> 
> protocols.  We can't put all these on separate ports or schemes (or can 
> we?)  
> 
> server.  For example, some certificate retrieval stuff works this way, 
> where a MIME type for the request advertises that the request contains a 
> detailed query and the response should include one or more certificates.
> 
> Is separate Content-Types is also a can of worms?  Does it amount 
> to content negotiation for format which is mostly considered a failure?  
> One doesn't need to see this as negotiation, but rather as an indication 
> what the application is.  
> 
> If most people just use application/xml as the Content-Type, then once 
> again we have undifferentiated traffic. Using http scheme, port 80 and 
> POST of application/xml gives nobody reasonable chance at filtering.
> 
> Is the content-type registration system easy enough, extensible enough?  
> Is that why they use application/xml?  Chris points out that registering 
> in vnd.* is easy, and we also have provisional registration.  So why 
> don't inventors of ad-hoc protocols use new MIME types?   Is it because 
> they can't be bothered?  Is the issue not one of simplifying the 
> process, but one of ownership?  Perhaps when a company asks for a 
> registration, they not only publicize their intent, they also tie 
> themselves down to one thing (one MIME type, scheme, or whatever) and 
> this is the basic reason people make excuses -- they just don't want to 
> limit their own actions like this.
> 
> Topic: Next meeting
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 9 Nov 2007 09:19:49 -0800

We didn't do a roll call.  However, these are the people I noted:

Philippe Le Hégaret
Thomas Roessler
Dan Connolly
Tim Berners-Lee
Chris Newman
Lisa Dusseault
Mark Nottingham
Dominique Hazaël-Massieux

Did I miss anybody or any accents on names?  :)

thx,
Lisa

On Nov 8, 2007, at 10:07 AM, Leslie Daigle wrote:

>> Thomas and Mark for taking the jabber notes.  Please send comments  
>> by Nov 13 so I can get these out (and by the way, what's the  
>> process for that?)
>> Lisa
>> ----- Agenda (after bashing on call): 1.  Work done by Content  
>> Transformation Task Force in the Mobile Web Initiative Best  
>> Practices Working Group -- Dominique Hazael-Massieux to join the  
>> call -- 15 min
>> requirements for disclosure?   IETF/Apps wouldn't force anybody to  
>> do things this exact way, but there may be lessons to be learned.   
>> For example, why has there been no uptake?  Apps ADs aren't aware  
>> of flaws in the technology, so it may be a socio-economic reason  
>> why there's no uptake (e.g. the people in a position to implement  
>> OPES aren't the people who want it)
>> Mention of call from semweb community to see what HTTP codes  
>> mean.  The definitions in the standard are sometimes ambiguous and  
>> some things aren't covered. Can the HTTP WG crisp up those  
>> definitions?  Lisa responded that this kind of effort, crisping up  
>> definitions of things that have already been standardized, seems  
>> to result in years worth of bitter arguments (e.g. discussion of  
>> what a lock was in WebDAV; arguments on resource instances  
>> occasioned by Mogul paper http://www2002.org/CDROM/refereed/ 
>> 444/).  HTTP has many such problems, see similar issues with  
>> resource, response, entity.  Conclusion was that for the semweb  
>> community to bring that up in the wider community at this point  
>> would mean more argument and no benefit.  Somebody suggested to  
>> Question about charter -- are test suites being developed?  The  
>> IETF, like W3C, doesn't do compliance outside specs.  The W3C,  
>> however, keeps test suites.  We think this is important for HTTP  
>> to crisp things up.  One thing the IETF has done is to produce an  
>> I-D or RFC that shows torture tests and the like: e.g. request and  
>> response messages in text form.  Producing the software of a test  
>> suite has never been a IETF WG deliverable, but it has been done  
>> closely with WGs.  Similarly, Interop events never done officially  
>> by an IETF WG, but in concert with one
>> royalty-free zone for some standards, it's awkward that HTTP isn't  
>> in there.   Lisa adds that there's no guarantee that HTTP isn't in  
>> the royalty-free zone; we just don't know because it was developed  
>> with a lot of things left unsaid about patent status.  In theory  
>> an IETF WG can include technology that is patented along with  
>> licensing assurances.  However, since the WG is revising HTTP  
>> without adding new inventions, it's unlikely that the WG can add  
>> anything that's known to be patented.  So HTTP's patent situation  
>> will likely remain the same: muddy, but no known problems.  We  
>> don't see a concrete action to take at this point.
>> NOTE that participants in HTTP WG have to disclose relevant  
>> patents even if the patents are not new. 3.  XMLsec workshop
>> Thomas sent e-mail about registering thes, was told to contact  
>> IANA; they came back and said to talk to the IESG.  Chris agreed  
>> to get that on the IESG agenda.  5/6.  BCP56, schemes and protocols
>> Issues about BCP56 have been coming up.  BCP56 was written with  
>> the experience of abuses of SMTP and other e-mail protocols  
>> overloading a single port.  It would be bad if use of port 80  
>> required firewalls and other intermediaries to get deep into the  
>> protocol to be able to ensure security or other services. On the  
>> other hand, we know that BCP56 isn't necessarily the best advice  
>> we could give today.   A new port example is IPP:  you can get at  
>> IPP resources with HTTP, but conventionally they're named ipp://  
>> and not on port 80.  However, there are more examples, and more  
>> recently, which do not use a new scheme nor a new port.  People  
>> want new protocols to be easy to implemen.  Atompub WG explained  
>> issue quite succintly -- want to be able to write atompub servers  
>> with java servlets or ruby on rails, without touching HTTP server  
>> engine.
>> Beyond this formal standards work, there are a huge number of ad- 
>> hoc protocols.  We can't put all these on separate ports or  
>> schemes (or can we?)  Another possibility, and perhaps more  
>> realistic, is to use separate content-types.  The content-type in  
>> the client request serves two functions, of explaining how to  
>> interpret the client request (schema and/or language) and also to  
>> request a particular service of the server.  For example, some  
>> certificate retrieval stuff works this way, where a MIME type for  
>> the request advertises that the request contains a detailed query  
>> and the response should include one or more certificates.
>> to content negotiation for format which is mostly considered a  
>> failure?  One doesn't need to see this as negotiation, but rather  
>> as an indication what the application is.  If most people just use  
>> application/xml as the Content-Type, then once again we have  
>> undifferentiated traffic. Using http scheme, port 80 and POST of  
>> application/xml gives nobody reasonable chance at filtering.
>> enough?  Is that why they use application/xml?  Chris points out  
>> that registering in vnd.* is easy, and we also have provisional  
>> MIME types?   Is it because they can't be bothered?  Is the issue  
>> not one of simplifying the process, but one of ownership?  Perhaps  
>> when a company asks for a registration, they not only publicize  
>> their intent, they also tie themselves down to one thing (one MIME  
>> type, scheme, or whatever) and this is the basic reason people  
>> make excuses -- they just don't want to limit their own actions  
>> like this.
>> Topic: Next meeting