Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt]

Hello Alex, others,

Sorry to be late with this answer. Please check 
draft-duerst-mailto-bis-07.txt (soon to appear) to see whether the 
updates are according to your expectations.

On 2009/10/17 4:49, Alexey Melnikov wrote:
> Martin J. Dürst wrote:
>
>> Hello Alex,
>
> Hi Martin,
>
>> On 2009/08/04 20:54, Alexey Melnikov wrote:
>>
>>> I believe I completed the todo item assigned to me during the Stockholm
>>> meeting.
>>
>> Many thanks for your review. Very helpful.
>>
>> > as it seems to be blocking some EAI drafts.
>>
>> Which? EAI seems to move forward nicely.
>
> I think it was either the "mailing lists" or the "downgrade" document.

Ok.

>> > In Section 2:
>> >
>> > addr-spec = local-part "@" domain
>> > local-part = dot-atom / quoted-string
>> >
>> > I don't think this change goes all the way to clarify that obsolete RFC
>> > 5322 syntax and comments are disallowed.
>> > RFC 5322:
>> > domain = dot-atom / domain-literal / obs-domain
>> >
>> > domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
>> >
>> > dot-atom-text = 1*atext *("." 1*atext)
>> >
>> > dot-atom = [CFWS] dot-atom-text [CFWS]
>> >
>> > atom = [CFWS] 1*atext [CFWS]
>> >
>> > obs-domain = atom *("." atom)
>> >
>> > I think "obs-domain" and "domain-literal" definitions are problematic
>> > (at least).
>>
>> I changed 'domain' too simply be 'dot-atom'. I hope this works.
>> (not exactly my area of expertise)
>
> I think a version of "domain-literal" which doesn't allow CFWS/FWS is
> also needed. E.g. to allow IPv6.
> Ok, this might be obscure. But I think earlier versions allowed for that.

Can you (or somebody else) tell me exactly what to do? For me, all this 
mail-related syntax is very unsure ground.



>> > 4. Percent-encoding can be used in the <domain> part of an <addr-
>> > spec>, in order to denote an internationalized domain name. The
>> > considerations for <reg-name> in [STD66] apply. In particular,
>> > non-ASCII characters must
>> >
>> > s/must/MUST ?
>> >
>> > first be encoded according to UTF-8
>> > [STD63], and then each octet of the corresponding UTF-8 sequence
>> > must
>> >
>> > s/must/MUST ?
>> >
>> > be percent-encoded to be represented as URI characters. URI
>> > producing applications must not
>> >
>> > s/must not/MUST NOT ?
>>
>> Fixed all of those. Sometimes adjusted wording, sometimes upper-casing
>> and sometimes using clearly non-normative wording.
>
> Ok.

Please check the newest draft.

>> > [...]
>> >
>> > MIME encoded words and UTF-8-based percent-encoding SHOULD NOT both
>> > be used sequentially in the same <hfvalue>, and MUST NOT be combined.
>> >
>> > Can you clarify what you are trying to say here?
>> > In particular I am not clear on the meaning of "sequentially" here.
>
>> Ok. Sequentially means e.g. using MIME for the first word in the
>> subject, and UTF-8-based percent-encoding for the second word.
>>
>> As for the "MUST NOT be combined", that either makes MIME completely
>> impossible ('?' and '=' used in MIME encoded words have to be
>> reencoded, but that isn't allowed) or leaves that provision hanging in
>> the air ('?' and '=' are US-ASCII, so UTF-8 is irrelevant when
>> percent-encoding them) depending on the interpretation of 'UTF-8'. So
>> that has to be fixed.
>>
>> First I was thinking about replacing the paragraph with something like:
>> "In mailto: URIs, UTF-8-based percent-encoding is preferred to MIME
>> encoded words because for the later, the '=' and '?' characters have
>> to be percent-encoded."
>>
>> But then that's also slightly inappropriate because MIME encoded words
>> may work in some old implementations where UTF-8 doesn't. Then I went
>> ahead and deleted that paragraph (because even 'sequential' mixing may
>> be okay assuming implementations peel off one encoding layer after the
>> other), and just inserted a short notice about the need to
>> percent-encode '=' and '?' in point 1. a few lines above.
>
> Some explanation of this in the document might be useful though.

I have looked through the document again. I think that points 1. and 2. 
(just after "Non-ASCII characters can be encoded in hfvalue as 
follows:") are perfectly enough.

There's also an example of both using UTF-8 and encoded-word syntax at 
the start of Section 6.3.

If you really think more is needed, then please propose some wording.


>> > In Section 3:
>> >
>> > In current practice, resolving URIs such as those in the 'http' URI
>> > scheme causes an immediate interaction between client software and a
>> > host running an interactive server. The 'mailto' URI has unusual
>> > semantics because resolving such a URI does not cause an immediate
>> > interaction. Instead, the client creates a message to the designated
>> > address with the various header fields set as default. The user can
>> > edit the message, send this message unedited, or choose not to send
>> > the message. The operation of how any URI scheme is resolved is not
>> > mandated by the URI specifications.
>> >
>> > The last sentence doesn't seem to be related to the rest of the
>> > paragraph. Should it be deleted or moved to a separate paragraph?
>>
>> This sentence is giving the motivation for why the paragraph starts
>> with "in current practice" and why there isn't a more normative
>> definition along the lines of "to resolve a 'mailto' URI scheme, you
>> MUST ...". So the position of this sentence seems okay to me. If you
>> have any proposal for how to make this clearer, I'll be glad to use that.
>
> It might be better to move this sentence to the beginning of this
> paragraph?

done.


>> > In Section 4:
>> >
>> > The creator of a 'mailto' URI cannot expect the resolver of a URI to
>> > understand more than the "subject" header field and "body".
>> >
>> > What about the "To" header field?
>>
>> I don't know too much about actual implementations, but the fact that
>> what corresponds to 'To' is usually given befor the '?' seems to
>> suggest to me that universal support for 'To' is neither necessary nor
>> therefore guaranteed.
>
> It might be good to do some research on this.
> If mailto URI parameters are handled at all, I would be expecting To and
> the address at the beginning to be always handled.

My expectation is different. The mailto scheme started just with the 
part before the '?', nothing else. Later, "Subject", and even later, 
"Body" were added, because they proved to be most useful (e.g. for 
subscription/unsubscription links,...). From such a historic viewpoint, 
"To" is least important, because it essentially just duplicates 
functionality. It's also more difficult to implement correctly than the 
average header field, because the data has to be merged.

Of course if somebody can come up with some research that shows 
something else, I'm glad to adjust the wording.


Regards,   Martin.


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

Received on Monday, 26 October 2009 07:53:01 UTC