Mobile Web Best Practices Working Group Teleconference

 

 

<trackbot> Date: 01 July 2008

<hgerlach> Hey isn't it Vodafone?????

scribe andrews

Re-chartering process

francois: Switch from informative to normative status of guidelines

<francois> rechartering questionnaire

francois: Please remind AC reps of questionnaire. Ends 28 July.

Issue 242

francois: Remaining issue. Views sent last Friday

<francois> fd's email

<francois> Sean's reply

francois: Overview of issue 242: About section 3.2. About control of proxy behaviour.
... Document is not clear whether there are controls for this part of guidelines.
... Need to move section 3.2 into section 4.
... Jo says we should not put policies into guidelines.
... Jo has pointed out that guidelines suggest that content servers should allow user selection of mobile or desktop versions but CT proxy would not know this choice is available.
... We should not try to reslove now but wait fo the updated draft.
... I propose that we remove section 3.2 and state controls in section 4.

<francois> PROPOSED RESOLUTION: goal is to integrate bits of current section 3.2 explicitly into current section 4, where ever they apply, for clarification purpose.

+1

Bryan: Previously made some proposals. [clarifying proposal]

francois: Risk is that guidelines could be too loose and anyone could claim compliance.
... Don't want to be too normative, too strict.

Bryan: People have different perspectives. Practice sometimes demands secondary mechanisms.

francois: We need to leave room for impementations to allow vendors room to deploy practically.

Bryan: CT is one component in proxy layer. In practice roles cannot be easily separated.

francois: Difficult to move all 3.2 into section 4.
... may result in a more obscure document.

But we should move as much as we can and be explicit when we can.

Bryan: We should use "should" whenever possible rather than "shall".

francois: In fact there are not many "must"s in the document so we don't force behaviour too much.

<francois> PROPOSED RESOLUTION: goal is to integrate as much of current section 3.2 as is practical to current section 4, where ever they apply, for clarification purpose.

+1

<Bryan> +1

<SeanP> +1

<francois> +1

RESOLUTION: goal is to integrate as much of current section 3.2 as is practical to current section 4, where ever they apply, for clarification purpose.

<francois> PROPOSED RESOLUTION: Move first bullet list in section 3.2.1 "Transformation proxies SHOULD provide to their users" to section 4.4.

<SeanP> +1

<francois> +1

RESOLUTION: Move first bullet list in section 3.2.1 "Transformation proxies SHOULD provide to their users" to section 4.4.

<francois> PROPOSED RESOLUTION: drop section 3.2.2, since it's already explicitly explained in section 4

+1

<SeanP> +1

<francois> +1

RESOLUTION: drop section 3.2.2, since it's already explicitly explained in section 4

francois: Now for the tricky part...
... Drop terms and conditions of service. These are out of scope of the document.

Sean: We should leave mention in document. Part of specifying user's choices is a practical matter.

francois: Allow list. This could be put into section 4 as an algortihm

hgerlach: Recommend an allow list for different user agent
... maybe the problem is the name "allow list". Maybe it should be called a "taylor list".

francois: Don't think the name is too important. Allow list is to enable sites to register on such a list but content providers would have to register on many lists and this would not be practical.
... We should allow an "allow list" but indicate that the list is refreshed from time to time so that the list evolves. This would allow evolving sites to be accommodated.

Bryan: Current wording is OK. Danger in softening wording and making it too general.
... Some content providers may not have the ability or means to put correct semantics into site so a list is a practical approach.
... 1st part of section is clear. Last sentence is probably too strict.

francois: If both parties agree how to handle content the guidelines do not need to be applied. This was agreed in the face-to-face meeting.
... In generic case, where there is no dialogue between CT provider and content provider, it would be difficult to have to apply to join lists for each operator.
... Better to have use of lists in scope and state when they apply.

SeanP: Agree with Bryan - language is a little too strong. Just need to state that in general lists can be impractical.

hgerlach: Different lists... bypass list is used today, likely to be small in future. But need an allow list to allow different user-agents for specific pages or URL or site.

Bryan: If we move the statements into the normative part of the document, it makes sense.
... Global allow list with specific exceptions should enable easy deployment.

hgerlach: No issue in updating bypass list, not sure that they will be changed regularly.

Bryan: 3.2.3 statements OK but not clear how these can be included in section 4

francois: There are problems for content providers when they do not know that they are on a list.
... Move lists to section 4?

Bryan: Does 3.2.3 add anything?

<francois> Request resource with original headers

<francois> - If the response is a 406 response, re-request with altered headers (unless the 406 response contains no-transform).

<francois> - If the response is a 200 response,

<francois> -- if the response contains vary: User-Agent, an appropriate link element or header, or no-transform, forward it

<francois> -- otherwise assess (by unspecified means) whether the 200 response is a bogus one

<francois> --- if it is not, forward it

<francois> --- if it is, re-request with altered headers

francois: Intention is to rewrite so that there is room for interpretation. In this case an allow list could be used.
... Give content transformation vendors freedom to implement

Bryan: Would change reference to bogus 200 response - this is not clear.

francois: Will summarise discussion in mailing list.