See also: IRC log
dka: any comments?
dka: new editors draft
<francois> new mobileOK draft
jo: document nearly
completed
... it will be easy change User-Agent change to take care
extensibility
<jo> PROPOSED RESOLUTION: Wording ref "exactly" should be modified under discussion of the User Agent header to allow implementations that are crawlers to add additional stuff identifying themselves
<dom> [I agree with francois this needs clarification]
francois: wondering about extending User Agent string
<dom> [I think we should allow for additional product tokens, additional comments]
<dom> [but making sure they first product token is the one set by the spec]
francois: discussing about additional comments should be at the beggining or ending of User Agent
<dom> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43
<dom> User-Agent = "User-Agent" ":" 1*( product | comment )
<dom> Syntax for Product tokens
<dom> http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2
<dom> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
<dom> comment = "(" *( ctext | quoted-pair | comment ) ")"
<dom> ctext = <any TEXT excluding "(" and ")">
<dom> quoted-pair = "\" CHAR
[dom, jo and francois arguing about the number of comments that could go in the user agent string]
<dom> The first product token should be "W3C-mobileOK/DDC-1.0"
<Bob_Cratchett> PROPOSED RESOLUTION: Change the wording of User Agent string in MobileOK Basic to say that the value MUST start with a product token containing W3C-mobileOK/DDC-1.0 and a comment containing (see ... yada yada)
<dom> +1
<jeffs> +1
<dom> yada yada = http://www.w3.org/2006/07/mobileok-ddc
+1
<DKA> +1
<Kai> +1
<jo> PROPOSED RESOLUTION: Change the wording of User Agent string in MobileOK Basic to say that the value MUST start with a product token set-to W3C-mobileOK/DDC-1.0 and a comment set to (see http://www.w3.org/2006/07/mobileok-ddc)
RESOLUTION: Change the wording of User Agent string in MobileOK Basic to say that the value MUST start with a product token set-to W3C-mobileOK/DDC-1.0 and a comment set to (see http://www.w3.org/2006/07/mobileok-ddc)
<jo> ACTION: Jo to confirm the EXACT wording of the proposed change to the user agent header on list to satisfy the growing needs of pednatry for the group [recorded in http://www.w3.org/2008/06/05-bpwg-minutes.html#action01]
<trackbot> Created ACTION-767 - Confirm the EXACT wording of the proposed change to the user agent header on list to satisfy the growing needs of pedantry for the group [on Jo Rabin - due 2008-06-12].
<dom> PROPOSED RESOLUTION: Pending Jo's change about user-agent, the group agrees to publish this document as a Last Call Working Draft, with a comments period of 3 weeks, with a proposal to move directly to PR if possible
RESOLUTION: Pending Jo's change about user-agent, the group agrees to publish this document as a Last Call Working Draft, with a comments period of 3 weeks, with a proposal to move directly to PR if possible
<DKA> +1
<jeffs> +1
<dom> +1
DKA: anything to discuss?
... in the process of making an input document. it'll be ready
for next call
<DKA> http://docs.google.com/Doc?id=dd3jk8v_114tkbg6kgj
<francois> [Re. CT: current schedule is to present a candidate draft for Last Call to the main body of the working group next week, to hopefully decide to publish the doc as Last Call during the F2F in Sophia]
<Zakim> jo, you wanted to wonder if the editors of BP2 will be there?
<francois> registration results
<dom> [Adam is planning on attending]
Kai: quick note on the
status of mobileOK Pro
... we have completed all the tests
... the task force has been asked to review the document
... will submit the document to the group as a whole shortly
DKA: will that be on time for the F2F?
Kai: probably, yes
DKA: so I think we should go
through it at the F2F
... so that we can give actions, decide its next steps,
Rec-track or not
Kai: the document might be better
served if we receive detailed feedback before the f2f
... and keep a high level discussion at the F2F meeting
<Zakim> jo, you wanted to note that the document has not received any proper attention in the body of the group
Jo: it's good that TF can focus
on specific items, but let's note that the group hasn't
considered the document in sufficient details
... I think it would be wishful thinking that people will get
into the details of the spec before the f2f
... esp. as we'll ask people to look at the CT guidelines in
more details for a LC
... so I think it might worth going through the document in
some details during the F2F
... and we certainly need to discuss its future
DKA: yeah, I think that would be
useful
... it was very useful for the CT document back in Seoul
... I'll take this as input to update the agenda
... is there any other logistical or process related issue we
need to discuss in the F2F?
Kai: What about POWDER and its connection to mobileOK?
DKA: will we have the right people there to discuss this? I don't think PhilA is attending
Jo: No, he isn't
Kai: I can give whatever information I have at the F2F if that helps the group decides
DKA: I think it's worthwhile to
put it on the agenda as informational
... but probably too early to make a decision
... (on whether we want to adopt it for mobileOK)
francois: we still need to
address the normative vs informative status of the CT
guidelines
... SeanP supported the idea of making the document
normative
... which would require a rechartering
DKA: good point, worth discussion
indeed
... I would prefer a normative document as well
... I'll put on the agenda
<Zakim> jo, you wanted to note that the normative language has been removed from the next draft ...
DKA: We can put this in the context of the charter extension
Jo: I've removed the "normative
status" language from the doc
... my preference would be that we issue the next LCWD
independently of the resolution of that question
francois: yeah, whatever the decision we make, there is no way we can publish the LCWD as normative in the next month
Jo: indeed
... as we know, we can have as many LC as we like
... if we agree to recharter, we can publish a 2nd LC
[note that the change of status wouldn't actually require a new LC, I believe]
<jeffs> if not charter for that now, don't do that now
dom: my understanding is that the only requirement is that there be at least 150 days between the first time the document is published as normative and its publication as Proposed Rec
DKA: if there are companies that have IPR that are associated with content transformation that might be attached with the guidelines
<jo> PROPOSED RESOLUTION: CT Guidelines to be issued as a non normative Last Call WD in accordance with the current charter, we'll review whether to make it normative separately
<jeffs> understands now... lawyers
DKA: if the document is normative, then the patents held by companies in the group needs to license on an RF-basis, right?
<Zakim> Kai_, you wanted to say that status of being normative does not change anything about existing patents
RESOLUTION: CT Guidelines to be issued as a non normative Last Call WD in accordance with the current charter, we'll review whether to make it normative separately
<jo> {Proposed text for CT Guidelines: <div2 id="sec-rfc2119">
<jo> <head>Interpretation of RFC 2119 Key Words</head>
<jo> <p>This document is not normative <phrase role="ednote">Need link to definition</phrase> and it is inappropriate to claim conformance to it. Implementors of this Recommendation who wish to promote effective inter operability of Web content will, however, interpret the key words
<jo> <rfc2119>must</rfc2119>, <rfc2119>must not</rfc2119>,
<jo> <rfc2119>required</rfc2119>, <rfc2119>shall</rfc2119>, <rfc2119>shall
<jo> not</rfc2119>, <rfc2119>should</rfc2119>, <rfc2119>should not</rfc2119>,
<jo> <rfc2119>recommended</rfc2119>, <rfc2119>may</rfc2119>, and
<jo> <rfc2119>optional </rfc2119>in this Recommendation as
<jo> described in <bibref ref="ref-rfc-2119"/> .</p>
<jo> </div2>
dom: big difference is that in
the informative case, participants are only required to
disclose patents of others they know about
... whereas in the normative case, any undisclosed patent falls
under the RF policy
SeanP: Reason to support "normative" was for legitimacy reasons, not really for patent issues. If that is not the case, then we're not strongly supporting the normative change.
DKA: OK, we'll have the discussion during the F2F
<manrique> see you
DKA: Session adjourned, thanks everybody