headers
Yves Lafon | 1 Aug 2008 14:26
Picon
Favicon
Gravatar

RE: i107


On Thu, 31 Jul 2008, Brian Smith wrote:

>
> Henrik Nordstrom wrote:
>> On tor, 2008-07-31 at 12:14 -0500, Brian Smith wrote:
>>> I assume by "the resource" you mean the resource at the original
>>> request URI, not the resource at the Content-Location URI.
>>
>> Content-Location IS the specific URI to this resource. Or if
>> you like the non-negotiated direct access URI to a specific
>> variant of a resource.

+1 (and btw, editing http://www.example.com/bar/ is quite painful as most 
servers won't give a CL with the "non-negotiated" URI (in this case it 
not really conneg)).

>>> RFC 2616 doesn't say that the client may delete any of the
>> variants of
>>> http://example.org/foo.html by sending a DELETE request to
>>> http://example.com/foo.html.
>>
>> To me it's exacly what it says. Quote from p3 6.7 Content-Location:
>>
>>    The Content-Location value is not a replacement for the original
>>    requested URI; it is only a statement of the location of
>>    the resource corresponding to this particular entity at the
>>    time of the request.
>
> example.org says that the entity that it is returning in the response is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julian Reschke | 1 Aug 2008 14:15
Picon
Picon

Issue 113, was: Proposed resolution for Issue 13 (language tags)


Felix Sasaki wrote:
> ...
> RFC 4647 defines a basic language range in sec. 2.1 which is the same as 
> the language range of sec. 14.4 of RFC 2616. Note also the information 
> in sec. 2.1 of RFC 4647:
> "Note that
> the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the
> use of digits anywhere in the 'language-range' (see [RFC2616errata])."
> So you could just refer to basic language ranges of RFC 4647 and be fine.
> ...

Indeed, thanks for pointing this out. I missed the fact that RFC 4647 
defines basic ranges. Will make a concrete proposal later on.

BR, Julian
Permalink | Reply | 38 comments |
headers
Henrik Nordstrom | 1 Aug 2008 14:49
Gravatar

RE: i107


On tor, 2008-07-31 at 17:37 -0500, Brian Smith wrote:

> In particular, the specification never says that the server SHOULD NOT or
> MUST NOT provide a Content-Location header when the predicate is false.
> AtomPub and other similar servers will often return a Content-Location
> header that doesn't uniquely identify a variant as I mentioned above.

Then this may need to be clarified.

Content-Location IS a unique object identifier, very similar to ETag,
except that it is not also a validator. There can be no two variants of
the same resource having the same Content-Location.

Content-Location is also supposed to be a unique URI directly addressing
a specific entity (variant) without negotiation. Methods using this URI
should address that specific variant of the resource.

> The Content-Location model fails because it requires a trust model that HTTP
> leaves undefined.

I still disagree on this. The level of trust needed for Content-Location
is not required at the protocol layer imho, and should be assumed by
application.

> I disagree. If the goal is to edit each language variant independently, then
> you need some mechanism to identify the individual variants as separate
> resources. HTTP itself doesn't define any mechanism for doing that; you need
> some extension. That extension might be an extension that simply says
> "Editing the resource at the Content-Location returned for X variant of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Smith | 1 Aug 2008 18:14
Favicon

RE: i107


Yves Lafon wrote:
> Ok, so add a CL in this case ? Ok, PUT will be done on 
> http://example.com/bar/foo.html.gz, then you didn't change 
> the original one and have two different document (with 
> different content) served using conneg on Accept-Encoding.
...
> Well, what kind of trust model would work? Are you trusting 
> the header and content you receive from an origin server, if 
> not sent using HTTPS?

Again, using Content-Location as a substitute URI for editing is going
beyond what RFC 2616 specifies. Whatever extension to HTTP that defines such
a scheme can define how everything works together.

> The existence of variants are orthogonal to the fact that 
> server have content negociated resource.
> 
> If you have /my-gf.png and /my-gf.jpeg, your intent is 
> probably to do fancy transcoding to update one when the other 
> is edited, because you know that there is a semantic link 
> between the two URIs, and the link is not the fact that 
> /my-gf is a conneg resource. In your example, doing a PUT on 
> /my-gf /my-gf.png or /my-gf.jpeg should in theory lead to the 
> same thing, update all versions, but it is way beyond what 
> HTTP gives you, it's server side logic for this particular 
> set of resources.

I agree, if I expose all three of those resources. But, in the example, only
one resource (with two variants) was exposed, not three separate resources.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominique Hazael-Massieux | 1 Aug 2008 18:30
Picon
Favicon
Gravatar

Review of Content Transformation Guidelines Last Call?


Dear HTTPBis Working Group,

The W3C Mobile Web Best Practices Working Group has been developing a
set of guidelines for Content Transformation proxies (i.e. non
transparent HTTP proxies) to address some of the needs identified in
particular on mobile networks.

These guidelines have just been published as a Last Call Working Draft:
http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/

The Last Call review period extends until September 16, and we would be
grateful if your group could review the document, in particular its
HTTP-related aspects.

Should that period prove too short for your group to review it, please
let us know so that we determine a possible extension of the review
period as needed.

Thanks,

Dominique Hazael-Massieux, Staff Contact of the Mobile Web Best
Practices Working Group
Permalink | Reply | 5 comments |
headers
Julian Reschke | 1 Aug 2008 21:05
Picon
Picon

Re: Issue 113, was: Proposed resolution for Issue 13 (language tags)


Julian Reschke wrote:
> 
> Felix Sasaki wrote:
>> ...
>> RFC 4647 defines a basic language range in sec. 2.1 which is the same 
>> as the language range of sec. 14.4 of RFC 2616. Note also the 
>> information in sec. 2.1 of RFC 4647:
>> "Note that
>> the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the
>> use of digits anywhere in the 'language-range' (see [RFC2616errata])."
>> So you could just refer to basic language ranges of RFC 4647 and be fine.
>> ...
> 
> Indeed, thanks for pointing this out. I missed the fact that RFC 4647 
> defines basic ranges. Will make a concrete proposal later on.

Proposed text:

-- snip --
6.4.  Accept-Language

    The Accept-Language request-header field is similar to Accept, but
    restricts the set of natural languages that are preferred as a
    response to the request.  Language tags are defined in Section 3.5.

      Accept-Language = "Accept-Language" ":"
                        1#( language-range [ ";" "q" "=" qvalue ] )
      language-range  =
                <language-range, defined in [RFC4647], Section 2.1>
(Continue reading)

Permalink | Reply | 37 comments |
headers
Frank Ellermann | 1 Aug 2008 22:43
Picon
Picon

Re: Issue 113, was: Proposed resolution for Issue 13 (language tags)


Julian Reschk wrote:

[...] 
>> Felix Sasaki wrote:
>>> ...
>>> RFC 4647 defines a basic language range in sec. 2.1
[...]

> Proposed text:
[...]

Fine.

> Each language-range MAY be given an associated quality value which
> represents an estimate of the user's preference for the languages

Optionally s/MAY/can/.  The syntax has it clear that "q=" <qvalue>
can be omitted.

Do you have a special reason to write "q" "=" instead of "q=" ?
Is this a place where you actually want some kind of *WSP "=" *WSP ?

> would mean: "I prefer Danish, but will accept British English and
> other types of English."

Maybe note that this list is not supposed to be sorted by <qvalue>s.

> The special range "*", if present in the Accept-Language field,
> matches every tag not matched by any other range present in the
(Continue reading)

Permalink | Reply | 34 comments |
headers
Julian Reschke | 2 Aug 2008 08:37
Picon
Picon

Re: Issue 113, was: Proposed resolution for Issue 13 (language tags)


Frank Ellermann wrote:
> Julian Reschk wrote:
> 
> [...] 
>>> Felix Sasaki wrote:
>>>> ...
>>>> RFC 4647 defines a basic language range in sec. 2.1
> [...]
> 
>> Proposed text:
> [...]
> 
> Fine.
> 
>> Each language-range MAY be given an associated quality value which
>> represents an estimate of the user's preference for the languages
> 
> Optionally s/MAY/can/.  The syntax has it clear that "q=" <qvalue>
> can be omitted.

+1

> Do you have a special reason to write "q" "=" instead of "q=" ?
> Is this a place where you actually want some kind of *WSP "=" *WSP ?

This is text inherited from RFC 2616. Let's discuss LWS issues 
separately from this issue.

>> would mean: "I prefer Danish, but will accept British English and
(Continue reading)

Permalink | Reply | 33 comments |
headers
Felix Sasaki | 2 Aug 2008 09:03
Picon
Favicon

Re: Issue 113, was: Proposed resolution for Issue 13 (language tags)


Julian Reschke さんは書きました:
>
> Julian Reschke wrote:
>>
>> Felix Sasaki wrote:
>>> ...
>>> RFC 4647 defines a basic language range in sec. 2.1 which is the 
>>> same as the language range of sec. 14.4 of RFC 2616. Note also the 
>>> information in sec. 2.1 of RFC 4647:
>>> "Note that
>>> the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the
>>> use of digits anywhere in the 'language-range' (see [RFC2616errata])."
>>> So you could just refer to basic language ranges of RFC 4647 and be 
>>> fine.
>>> ...
>>
>> Indeed, thanks for pointing this out. I missed the fact that RFC 4647 
>> defines basic ranges. Will make a concrete proposal later on.
>
> Proposed text:

looks fine to me as well. Re case-insensitive, see mail from Frank.

Felix

>
> -- snip --
> 6.4.  Accept-Language
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill de hOra | 2 Aug 2008 20:55
Favicon
Gravatar

Re: Quota Enforcement and the communication of violations of policy using HttpStatusCode's.


I've had similar concerns, but nonetheless I think 507 with qualifying 
text is better than cutting a new code (or using 403, which I associate 
with a  permissions issue, rather than an exceeded constraint).

Bill

Jeff Currier wrote:
> Julian,
> 
> After reading a bit more on the use 507 status code I'm still concerned that this is very much related to
Storage and would not be broad enough to encompass all the of the scenarios that we have (bandwidth quota
violations, storage violations, application object quota violations, etc).  It still seems that a more
general status code is needed.
> 
> Now, to Robert's earlier mention of the use of 403.  The concern there again is still the idea that people
will confuse this with the password issue.  I appreciate that the spec does call out that the request was
correctly formed, the server understood the request and that the reissue of the request will have no
effect but in practice most users, IMHO, will simply only check their passwords.  I think the fact that we
see so many other services not using 403 for this sort of thing supports this conclusion.
> 
> 
> Regards,
> 
> --Jeff--
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@...]
> Sent: Tuesday, July 29, 2008 3:11 PM
> To: Jeff Currier
(Continue reading)

Permalink | Reply | 0 comments |

Gmane