Re: Sluggish member resources

[Tim Bray <Tim.Bray@xxxxxxx>]

On Apr 16, 2007, at 6:02 AM, Bill de hOra wrote:

> > Yeah, I'm with Nikunj.  Slug really only exists for public-facing  
> > URIs, and the spec should say so. -Tim
>
> Earlier you said it didn't matter whether it shows up in the member  
> URI; this sounds like it matters that it doesn't.

Well, "member URI" is not sufficiently specific. It clearly doesn't  
hurt for the Slug to show up in any URI.  The idea is that you the  
client are asking for it to be used in what my suggested spec text  
called "The URI normally used for retrieving the newly-created  
resource."

> I assume "public facing" == "entry/content@src". I'd like to say  
> the latter in the spec as 'public facing' is highly unspecific.  
> Please review the example:
>
> <http://bitworking.org/projects/atom/draft-ietf-atompub- 
> protocol-14.html#mle-example>

It *might* be a good idea to take the slug out of the Location-header  
URI just to underline the point about the expected usage.

> and let me know whether the fact the link URLs also have the slug  
> embedded is actually a problem.  I can try to wordsmith this, but  
> further specification (eg turning "only exists for" into spec  
> language) requires a consensus call.

Nobody suggested "only exists for" as spec text.  The suggestion is  
that sending the Slug constitutes a request by the client that the  
slug text be used in the URI normally used to retrieve the newly  
created resource, and I *think* (without doing an exhaustive email  
review) that is a consensus position. -Tim