Erik Wilde | 1 Mar 02:25 2010
Picon

Re: fb: URIs?

hello.

Graham Klyne wrote:
> Erik Wilde wrote:
>> would it help at all to have X-... uri schemes that analogous to other 
>> named things on the internet by definition always would be local and 
>> context-specific? at least, somebody like facebook then could, if they 
>> wanted to, choose X-fb://... URIs and it would be clear that those 
>> were URIs which should be handled with care and in a certain context...
> It seems to me that the developers concerned would do better to 
> introduce a syntactically *invalid* form of scheme name for internal use 
> (e.g. ~fb: ?), rather than bless the local practice in a standard.  This 
> way, there's no question of confusion caused by leakage to into the wild.

the problem with that is that tools might not like that. i guess the 
"misuse" of URI schemes is caused by convenience in the first place, and 
if you violate the technology that is chosen to make life easier, then 
it's very likely that a lot of tools will complain, and then you gain 
not all that much. or even worse, you may start "improving" the tools to 
also work with the invalid, proprietary "syntax". i don't think that 
would be such a good way to go.

cheers,

dret.

steven | 2 Mar 13:17 2010
Picon

Как освободиться от смертельной зависимости

День добрый

Конструктор индивидуальной методики - ОТКАЗА ОТ КУРЕНИЯ
Скорректируйте методику под свой организм!
Мы представляем Вам новейший конструктор методики,
который создан наши разработчики совместно с экспертами.

Может использоваться даже теми, кто уже безуспешно
пытался бросить курить

http://glorify6142.spaces.live.com

Случайный факт о курении: В 10 раз возрастает риск
умереть от легочной инфекции и рака гортани

massimo | 3 Mar 08:10 2010
Picon

Курение одинаково быстро убивает мужской и женский организм

Приветствую вас

Конструктор индивидуальной методики - ОТКАЗА ОТ КУРЕНИЯ
Скорректируйте методику под свой организм!
Мы представляем Вам новейший конструктор методики,
который создан наши разработчики совместно с экспертами.

Подходит и мужчинам и женщинам независимо от
состояния здоровья

http://phosphorescent16.spaces.live.com

Случайный факт о курении: В 6 раз возрастает риск
умереть от болезней сердца

massimo | 3 Mar 10:23 2010
Picon

Как бросить самую отвратительную и вредную привычку

День добрый

Конструктор индивидуальной методики - ОТКАЗА ОТ КУРЕНИЯ

Вы не будете зависеть от сигарет √ сможете свободно
путешествовать, проводить время с друзьями и не
думать о том, сколько сигарет у вас осталось

http://begun94.spaces.live.com

Печальный факт о курении: В 12 раз возрастает риск
умереть от рака легких

Michael A. Puls II | 5 Mar 00:19 2010
Picon

Re: data URIs - filename and content-disposition

On Fri, 26 Feb 2010 08:20:39 -0500, Julian Reschke <julian.reschke <at> gmx.de>  
wrote:

> On 25.02.2010 17:06, Michael A. Puls II wrote:
>> ...
>> What about this?
>>
>> Say you have this file:
>>
>> "with spaces.txt"
>> ---------
>> √
>> ---------
>>
>> and want that as data URI that's treated as an attachment with a
>> filename hint of "with spaces.txt".
>>
>> Well, you might want headers like this:
>>
>> Content-Type: text/plain; charset=utf-8
>> Content-Disposition: attachment; filename="with spaces.txt"
>> Content-Language: en
>>
>> So, how bout doing it like the following?:
>>
>> data:text/plain;charset=utf-8;headers=Content-Disposition%3A%20attachment%3B%20filename%3D%22with%20spaces.txt%22%0D%0AContent-Language%3A%20en,%E2%88%9A
>>
>>
>> That way, 'text/plain;charset=utf-8' would be the full Content-Type
>> header and the rest of the headers can be specified as \r\n-separated
(Continue reading)

Joe Gregorio | 7 Mar 01:07 2010

Legal URI Templates

Just checking, I believe that the following are all legal URI Templates according to the latest revision:


  {2}
  {%20}
  {☄}

Which does lead to the question of whether
the following are equivalent templates:

  {a}
  {%61}

Previous drafts used 

    varname = (ALPHA / DIGIT)*(ALPHA / DIGIT / "." / "_" / "-" )

which avoided this ambiguity.

   Thanks,
   -joe

  
Roy T. Fielding | 7 Mar 02:15 2010

Re: Legal URI Templates

On Mar 6, 2010, at 4:07 PM, Joe Gregorio wrote:

> Just checking, I believe that the following are all legal URI Templates according to the latest revision:
> 
>   {2}
>   {%20}
>   {☄}
> 
> Which does lead to the question of whether
> the following are equivalent templates:
> 
>   {a}
>   {%61}

I think they should be equivalent -- will need to note that
in the variable name parser.

> Previous drafts used 
> 
>     varname = (ALPHA / DIGIT)*(ALPHA / DIGIT / "." / "_" / "-" )
> 
> which avoided this ambiguity.

Yes, I gave in to the requests for full i18n support since
some people might want to use them in non-LTR character encoded
documents.  *shrug*

....Roy

"Martin J. Dürst" | 8 Mar 03:20 2010
Picon

Re: Legal URI Templates


On 2010/03/07 10:15, Roy T. Fielding wrote:
> On Mar 6, 2010, at 4:07 PM, Joe Gregorio wrote:

> Yes, I gave in to the requests for full i18n support since
> some people might want to use them in non-LTR character encoded
> documents.  *shrug*

Should that be non-ASCII characters instead of non-LTR characters (which 
would be RTL, i.e. right-to-left, i.e. Arabic and Hebrew and such)?

Regards,   Martin.

--

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst <at> it.aoyama.ac.jp

Roy T. Fielding | 8 Mar 04:26 2010

Re: Legal URI Templates

On Mar 7, 2010, at 6:20 PM, Martin J. Dürst wrote:
> On 2010/03/07 10:15, Roy T. Fielding wrote:
>> On Mar 6, 2010, at 4:07 PM, Joe Gregorio wrote:
> 
>> Yes, I gave in to the requests for full i18n support since
>> some people might want to use them in non-LTR character encoded
>> documents.  *shrug*
> 
> Should that be non-ASCII characters instead of non-LTR characters (which would be RTL, i.e.
right-to-left, i.e. Arabic and Hebrew and such)?

Yes and no.  Yes, it applies to all non-ASCII encodings.
No, I was not convinced it was useful to have non-ASCII
variable names until I considered the effect it would have
on documenting IRI templates in an RTL language.

That was just my personal tipping point.  There were
already requests for the feature in general, but it adds
complexity to all parsers and thus needed justification.

....Roy

Roy T. Fielding | 10 Mar 01:20 2010

Fwd: I-D Action:draft-gregorio-uritemplate-04.txt

[second attempt to send this]

I managed to submit a new draft, just before the deadline,
with the obsolete sections removed and the sections that
still need writing marked as TBD.

The current issues (that I am aware of) include:

1) error handling -- as Joe noted, we can improve consistency
by making every error in the template result in a semi-expanded
result string and error indicator, rather than nulling
the result string and returning immediately.  My preference is
to copy bad expressions to the result, continue processing, and
indicate an error occurred to the caller.  This allows the
calling application to use the result string to point out
where the processing failed.

2) reserved substitution -- this is currently allowed only
by the "+" operator.  A suggestion by Mike Burrows is that the
"+" operator be changed into a variable name prefix so that
it can be selectively applied to any variable in any expression.
In addition to the added power, I found that a prefix would
simplify the value expansion description (and algorithm).
However, I have not made that change yet in 04.  Would such
a change be compatible with XRD and other applications?

3) I introduced explode modifiers, with the named variable
version indicated by a trailing "+" on the name.  Perhaps that
would be better as a trailing " <at> " if we do (2) above.

4) James Manger suggested several changes to the syntax:

  a) remove the variable lists and instead have the processor
     maintain a memory of where it is in the URI generic syntax
     to know when to add the default ";" or "?" delimiters.
     Add a comma operator to support CSV expansions.

  b) change the default syntax to {var|default} instead of
     {var=default}, in order to allow ...

  c) define variable bindings within the template itself so
     that large schemas like OpenSearch can directly annotate
     every variable inside the template as opposed to annotating
     them by reference outside the template.  e.g.,

        find{?q=searchTerms}{?lang=language}

    I personally find (a) significantly uglier than the
    existing syntax;  (b) okay if people haven't implemented
    defaults yet; and, (c) a very slippery slope that, IMO, will
    result in the equivalent of WADL being embedded inside the
    template instead of remaining outside (where it can be safely
    ignored by RESTful applications).  YMMV.

I will be at the Anaheim IETF if anyone wants to discuss these
issues in person, but please send email to the list if you want
the discussion to result in changes to the next draft.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Begin forwarded message:

> From: Internet-Drafts <at> ietf.org
> Date: March 8, 2010 5:00:01 PM PST
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-gregorio-uritemplate-04.txt 
> Reply-To: internet-drafts <at> ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : URI Template
> 	Author(s)       : J. Gregorio, et al.
> 	Filename        : draft-gregorio-uritemplate-04.txt
> 	Pages           : 25
> 	Date            : 2010-03-08
> 
> A URI Template is a compact sequence of characters for describing a
> range of Uniform Resource Identifiers through variable expansion.
> This specification defines the URI Template syntax and the process
> for expanding a URI Template into a URI, along with guidelines for
> the use of URI Templates on the Internet.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-04.txt


Gmane