headers
Mark Nottingham | 1 Jul 06:23
Favicon
Gravatar

Re: Clarifications on Web Linking with HTTP

type is in the BNF, just not the prose; will say something in the next  
draft.

Thanks,

On 30/06/2009, at 9:49 PM, Sam Johnston wrote:

> On Tue, Jun 30, 2009 at 6:20 AM, Mark Nottingham <mnot <at> mnot.net>  
> wrote:
> Hi Sam,
>
> Thanks for getting back to me about this - your input is appreciated.
>
> On 15/06/2009, at 1:27 PM, Sam Johnston wrote:
>
> - First and foremost, in the absence of the LINK and UNLINK verbs
> originally defined in RFC 2068[2] but specifically omitted from RFC
> 2616[3], what is the preferred mechanism for manipulating these links
> via HTTP? <snip>
>
> Undefined, but I imagine in a PUT/POST body does indeed make the  
> most sense. Using the Link header in a request doesn't have well- 
> defined semantics.
>
> I think it would be something that's worth defining, albeit perhaps  
> not in your current I-D at the 11th hour and after 6 revisions. It's  
> just not clear to me what (outside of dedicated HTTP verb(s)) makes  
> the most sense... I'm yet to come up with a reasonable way to do it  
> in-band.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 1 Jul 16:47

Re: URI for abstract concepts (domain, host, origin, site, etc.)

Dan Brickley wrote:
> This is an interesting design! I need to think about it a bit more. I 
> expect it would cause some pressure for shorter media-type names. Hmm 
> from http://www.iana.org/assignments/media-types/ ... "model", hadn't 
> noticed that... http://www.iana.org/assignments/media-types/model/ maybe 
> #(model/rdf)blahblah is worth thinking about too. Not sure this is great 
> from an I18N perspective, if it forces people to put English script into 
> IRIs that might otherwise be all in another script...

As I recall, model/... is specifically intended for descriptions of 
3-dimensional physical structures (virtual reality data, etc.).  Cf. 
http://www.rfc-editor.org/rfc/rfc2077.txt

#g
Permalink | Reply | 0 comments |
headers
William F. Maton Sotomayor | 1 Jul 21:53
Picon

Interest in reviving WG on FTP(maybe ext?)


All,

 	Over the past several months a colleague at a university and 
myself have revived work on the WU-FTPD daemon.  Through researching the 
various RFCs and such, it's become apparent that there are a small number 
of drafts as well as a potential number of others that could significantly
contribute to the protocol.  (So my voyage has gone from operator, 
developer and implementor to protocol spec.)  But, ftpext wound-up and it 
seems there's no specific venue to flesh these out amongst like-minded 
FTP people.

 	I suppose what I'm looking for from the Apps Area folk is to test 
the waters on establishing a BoF (if I have read the Apps website 
correctly) that will lead to establishing some kind of group that will 
further the possible work remaining or possibly poending to be done, or 
not.  Discussions amongst a couple of authors of long-expired drafts seem 
to favour some kind of venue.

Thanks,

wfms
Permalink | Reply | 7 comments |
headers
Mark Nottingham | 2 Jul 11:58
Favicon
Gravatar

FYI: Bar BoF wiki pages

I've created some wiki pages to plan and track Bar BoFs at:
   http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75

Cheers,

--
Mark Nottingham     http://www.mnot.net/
Permalink | Reply | 0 comments |
headers
David Booth | 1 Jul 16:07

RE: URI for abstract concepts (domain, host, origin, site, etc.)

Larry,

On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote:
> I'm thinking about revising
>  http://larry.masinter.net/duri.html
> 
> to:
> (1) to get rid of "duri" and just stick with "tdb"
>   (because there isn't much use for duri at all)
> (2) make it a URI scheme rather than a URN namespace
> (3) make the date optional, for cases where the time of
>   binding resource to representation (and of interpretation
>   of that representation to an 'abstract concept')
> 
> So the simplest form would be
> 
> tdb:http://larry.masinter.net

That makes it remarkably similar to
http://t-d-b.org?http://larry.masinter.net

but the t-d-b.org URI has the advantage that it doesn't require a new
URI scheme, and it *might* be dereferenceable by a browser.  In fact, at
the moment it *is* dereferenceable. 

> 
> which would neatly allow using descriptions of
> abstract concepts to identify the abstract concept.

That sounds like what the "http://t-d-b.org?" prefix does.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Eran Hammer-Lahav | 2 Jul 18:49
Favicon
Gravatar

RE: URI for abstract concepts (domain, host, origin, site, etc.)

But this approach means a parser cannot figure out the meaning of a URI without a GET. How would a parser know
that a document about such a URI is really about something else (the subject of the URI) and not the resource
the URI itself is identifying?

For this to work, I need to hardcode http://t-d-b.org into every parser to have a specialized meaning.

EHL

> -----Original Message-----
> From: David Booth [mailto:david <at> dbooth.org]
> Sent: Wednesday, July 01, 2009 7:08 AM
> To: Larry Masinter
> Cc: 'Jonathan Rees'; ashok.malhotra <at> oracle.com; Eran Hammer-Lahav;
> apps-discuss <at> ietf.org; www-tag <at> w3.org; 'URI'
> Subject: RE: URI for abstract concepts (domain, host, origin, site,
> etc.)
> 
> Larry,
> 
> On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote:
> > I'm thinking about revising
> >  http://larry.masinter.net/duri.html
> >
> > to:
> > (1) to get rid of "duri" and just stick with "tdb"
> >   (because there isn't much use for duri at all)
> > (2) make it a URI scheme rather than a URN namespace
> > (3) make the date optional, for cases where the time of
> >   binding resource to representation (and of interpretation
> >   of that representation to an 'abstract concept')
(Continue reading)

Permalink | Reply | 7 comments |
headers
Pat Hayes | 3 Jul 00:06
Picon
Gravatar

Re: URI for abstract concepts (domain, host, origin, site, etc.)


On Jul 2, 2009, at 11:49 AM, Eran Hammer-Lahav wrote:

> But this approach means a parser cannot figure out the meaning of a  
> URI without a GET. How would a parser know that a document about  
> such a URI is really about something else (the subject of the URI)  
> and not the resource the URI itself is identifying?
>

Why would a *parser* need to know such a thing? A reasoner could know  
this by having access to some sentences that told it what the URI  
refers to. I don't know of any other general way that any entity,  
including a human being, could know what a URI was intended to denote.

> For this to work, I need to hardcode http://t-d-b.org into every  
> parser to have a specialized meaning.

No, you just have to know that it indicates that the URI refers to  
*something*. Since URIs can (be used to) refer to anything, it isnt  
possible to have a "specialized" meaning.

Pat

>
> EHL
>
>> -----Original Message-----
>> From: David Booth [mailto:david <at> dbooth.org]
>> Sent: Wednesday, July 01, 2009 7:08 AM
>> To: Larry Masinter
(Continue reading)

Permalink | Reply | 2 comments |
headers
Erik Wilde | 3 Jul 02:22
Picon
Favicon
Gravatar

Re: URI for abstract concepts (domain, host, origin, site, etc.)

On Jul 2, 2009, at 15:06, Pat Hayes <phayes <at> ihmc.us> wrote:
Why would a *parser* need to know such a thing? A reasoner could know this by having access to some sentences that told it what the URI refers to. I don't know of any other general way that any entity, including a human being, could know what a URI was intended to denote.

that's the semantic web world view, where URIs are completely opaque, always supposed to be http:, and to learn anything about them, a description must be found and used. on the plain web, URI schemes carry semantics, so that a client needs no additional information about tel: to be able to use these URIs. of course, the semantic web methods of describing something are far richer, but that should not imply that all URI semantics are or should be deferred to semantic web technologies.

cheers,

dret.
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Permalink | Reply | 0 comments |
headers
Salvatore Loreto | 3 Jul 18:25
Picon
Favicon

HyBi Bar BoF

Hi there,

I'd like to know if people are interested and available to join a *Bar 
BoF on HyBi* in Stockholm at IETF 75.

*Details*

    * When: TBD
    * Where: TBD

*Topics:*
- the "near term" solutions to the problem of using HTTP for 
bidirectional exchanges :
  on which, if any, aspect among the one listed in 
draft-loreto-http-bidirectional-00
  folks think it would be most productive to focus on.

- the "long term" solution...
  clarify the term of the agreement between W3C and IETF,
  and start to discuss on the requirements.

/add suggested topics of discussion as appropriate/

*Resource:*
/(add drafts and other links as appropriate)
/- 
http://www.ietf.org/internet-drafts/draft-loreto-http-bidirectional-00.txt/

/
Thanks
Sal/
www.sloreto.com

/
Permalink | Reply | 8 comments |
headers
George Michaelson | 3 Jul 01:05
Picon
Favicon

IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing

I would like to suggest that IMAP extensions could usefully be  
specified to permit MUA to signal to the MS over IMAP, that the  
message in question is, or is not spam. I would also like to suggest  
that an IMAP extension pair to signal that the specified address is to  
be white, or black listed, would be equally useful.

This is because a large number of people now depend on IMAP backed MS  
in places like google, or corporate maildrops, but also have in-client  
spam tagging. Where the spam filtering is not sufficiently complete to  
prevent significant leakage, and mis-attribution across the MUA/MS  
dialogue, the lack of an in-protocol method to pass the information  
means we are all using what I would call ad-hoc methods to fix this  
situation up.

If it was possible to communicate this 'first class' in IMAP, I think  
that it would significantly enhance the user experience.

As an example, at the moment if I wish to inform google that I have  
known spam in local folders, I have to go to the web interface and  
manually tag. If there was an IMAP extension, I could review my local  
baysian junk folder, remove all non-spam (and flag the senders as  
white-listed if need be), and request the rest to be flagged as spam  
back on the IMAP backed MS.

Likewise for false positives and blacklisted senders.

I am told that the IMAPEXT WG is closed. I mail this, in the hope that  
somebody can help decide if this is a viable topic for consideration.

Many thanks for guidance and advice thus far from Lisa Dusseault.

cheers

-George
Permalink | Reply | 58 comments |

Gmane