W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

ACTION-900 CT Dangling Ends

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 24 Mar 2009 21:33:25 +0000
Message-ID: <49C951A5.2080603@mtld.mobi>
To: Public MWBP <public-bpwg@w3.org>
In preparation for the F2F here is the list of Dangling Ends I have found



a) Last Call Comments from the previous last call

Open  LC-2025 and LC-2053
Proposal LC-2043 LC-2097 LC-2089 LC-2040
Pending LC-2051

And the rather long list referred to ref HTTPS links referred to under
b) below.

b) Not completely implemented resolutions - note from last draft 1p

http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0044.html

c) OPES

http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0045.html

This has some new wording  in the current draft 1q not at odds with the
resolution subsequently taken but should be reviewed

d) Abstract - from Matt Womer

inter-work? And it needs rewording to reflect bumping CP stuff into an 
appendix

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090313#abstract

e) A few typos, from Francois

http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0108.html

f) Outstanding Issues and Actions

http://www.w3.org/2005/MWI/BPWG/Group/track/products/12

Including this ACTION-900

g) Rotan's point

= = =
ISSUE: The CT document is missing some statement recognising the role
and expectations of the main parties (author, consumer, transformer) and
the need for mutual understanding and respect of the others'
needs/expectations. Perhaps also some suggestion from the BPWG on how to
prioritize the different needs/expectations would be useful, as a
general principal, especially given that there will be conflicts to
resolve.
= = =

Actually, we used to have a statement on this, in past revisions, but it 
is gone, like dew in the morning. Can't remember why. Shall we put it back?


h) Editorial Notes in the Current Draft 1q

4.1.5 Alteration of HTTP Header Field Values

Editorial Note: Note that the need for copies of the original header 
values is (once again) in question.

Editorial Note: Note that the question of whether alteration of the 
User-Agent field solely in order to avoid a 406 response has *seemingly* 
not been answered definitively

4.1.6.1 Proxy Treatment of Via Header Field

Editorial Note: I don't know why this is useful. What is a server 
expected to do as a result?

4.2.7 Link to "handheld" Representation

If the response is an HTML response and it contains a <link 
rel="alternate" media="handheld" /> element, a proxy should request and 
process the referenced resource, unless the resource referenced is the 
current resource as determined by the presence of link elements as 
discussed under D.1.3.2 Indication of Intended Presentation Media Type 
of Representation. [[oops a reference to something that isn't normative 
any more]]

4.2.8 WML Content

If the content is WML [[or WBMP?]] proxies should act in a transparent 
manner.

4.2.9 Proxy Decision to Transform

Editorial Note: Much of this needs to be re-organised ref resolutions on 
Mandatory heuristics, however pursuant to the resolution:

Editorial Note: The editor notes that the BPWG seeks further examples of 
heuristics.

4.2.9.2 HTTPS Link Re-writing

Editorial Note: Note that the following is under active discussion. One 
view says that HTTPS link rewriting is unacceptable under any 
circumstances. Note also that the question of whether it is acceptable 
to rewrite any link has been opened (because of security considerations 
relating to [same domain] concerns)

...

Note:

The BPWG does not condone link rewriting, but notes that in some 
circumstances HTTPS is used in situations where the user is prepared to 
trade usability provided by a transforming proxy for the loss of 
end-to-end security. Servers can prevent users from exercising this 
choice by applying a Cache-Control: no-transform directive.

Editorial Note: 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html g) 
and others ...

...

When forwarding responses from servers proxies must notify the user of 
invalid server certificates.

[[Add some stuff below under guidance for servers]]

5 Testing (Normative)

...

The interface must be reachable from terminals with browsing 
capabilities connected to the Web via a conventional Internet access 
environment at the tester's premises; accessing the interface may 
necessitate adjusting standard Web browsing configuration parameters -- 
such as specifying a proxy IP address and port on a desktop browser, or 
activating a WAP setting on a mobile browser.

Editorial Note: Does this need to be publically accessible?


B Conformance Statement

See example conformacne statement from Francois (link below) and his 
covering note

D.1.3.2 Indication of Intended Presentation Media Type of Representation

...

If content for more than one presentation media type is served from the 
same URI, it is better not to use a link element identifying the 
presentation media types as the URI will appear to be a "same document 
reference", indicating to a client that this representation is suitable 
for all the named presentation media types. Instead, use a Vary HTTP 
header field indicating that the response varies according to the 
received User-Agent HTTP header field.

I'm really not sure this is right actually. Think we need to bang on the 
TAG's door again.


E Examples of Internet Content Types, DOCTYPEs and URI Patterns 
(Non-Normative)

Internet Content Types that are sometimes or usually associated with 
content intended for delivery to mobile devices:

Editorial Note: 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html h) 
and Mandatory Heuristics ...














-------------
Jo Rabin
CTO
dotMobi (mTLD Top Level Domain Limited)
O: +353 1 854 1144
M: +353 87 066 7327

mTLD Top Level Domain Limited is a private company limited by shares,
incorporated and registered in the Republic of Ireland with registered
number 398040 and registered office at Arthur Cox Building, Earlsfort
Terrace, Dublin 2.
Received on Tuesday, 24 March 2009 21:34:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC