"draft-wilde-sms-uri-19" available

[Erik Wilde-3]

dear IESG.

with this email i would like to announce that the internet draft
entitled "URI Scheme for GSM Short Message Service" has just been
updated to version draft-wilde-sms-uri-19.

this new version of draft-wilde-sms-uri updates draft-wilde-sms-uri-18.
  the text and html versions of the submitted draft can be found at the
  following locations (and in the relevant IETF places):

http://dret.net/netdret/docs/draft-wilde-sms-uri-19.txt
http://dret.net/netdret/docs/draft-wilde-sms-uri-19.html

the draft's abstract reads:

This memo specifies the Uniform Resource Identifier (URI) scheme "sms"
for specifying one or more recipients for an SMS message. SMS messages
are two-way paging messages that can be sent from and received by a
mobile phone or a suitably equipped networked device.

thanks a lot and kind regards,

erik wilde   tel:[phone] - fax:[phone]
        dret@...  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

[Dan Brickley-2]

(Cc: trimmed)

On Mon, Aug 24, 2009 at 3:24 AM, Erik Wilde<dret@...> wrote:

> dear IESG.
>
> with this email i would like to announce that the internet draft entitled
> "URI Scheme for GSM Short Message Service" has just been updated to version
> draft-wilde-sms-uri-19.
>
> this new version of draft-wilde-sms-uri updates draft-wilde-sms-uri-18.  the
> text and html versions of the submitted draft can be found at the  following
> locations (and in the relevant IETF places):
>
> http://dret.net/netdret/docs/draft-wilde-sms-uri-19.txt
> http://dret.net/netdret/docs/draft-wilde-sms-uri-19.html
>
> the draft's abstract reads:
>
> This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for
> specifying one or more recipients for an SMS message. SMS messages are
> two-way paging messages that can be sent from and received by a mobile phone
> or a suitably equipped networked device.
>
> thanks a lot and kind regards,
>
> erik wilde   tel:[phone] - fax:[phone]
>       dret@...  -  http://dret.net/netdret
>       UC Berkeley - School of Information (ISchool)

Looking at the abstract and examples, the scope isn't very clear to me.

http://dret.net/netdret/docs/draft-wilde-sms-uri-19.html#uri-examples

 "for specifying one or more recipients for an SMS messages"

- grammar seems funny; "recipients for an SMS message" or "recipients
for SMS messages"
- does an sms: URI identify a recipient in general, or a recipient in
the context of some specific message? I assumed former until I saw
sms:[phone]?body=hello%20there

"In this case, a message (initially being set to "hello there", which
may be modified by the user before sending) will be sent via SMS using
the user agent's default SMS delivery method."

It might help if you list the classes of thing that this scheme
provides identifiers for? ie. an sms: URI could be an identifier for

 - a single sms-capable account
 - a list of sms-capable accounts
 - one or more accounts plus a draft message

cheers,

Dan

[Erik Wilde-3]

hello dan.

Dan Brickley wrote:
> Looking at the abstract and examples, the scope isn't very clear to me.
> http://dret.net/netdret/docs/draft-wilde-sms-uri-19.html#uri-examples
>  "for specifying one or more recipients for an SMS messages"
> - grammar seems funny; "recipients for an SMS message" or "recipients
> for SMS messages"

i don't see where you copied that text, it seems to me there are two
locations saying "one or more recipients for an SMS message", but i
could not find the text you pasted here. maybe you looked at an older
version?

> It might help if you list the classes of thing that this scheme
> provides identifiers for? ie. an sms: URI could be an identifier for
>  - a single sms-capable account
>  - a list of sms-capable accounts
>  - one or more accounts plus a draft message

the difficulty may be that the intent of the scheme is to allow the
sending of one message logically speaking, but since SMS does not have
the capabilities to send one message to more than one recipient, on the
SMS level this maps to a number of messages being sent, one to each
individual recipient. since there are individual messages, they could be
different, but the intent is that if multiple messages are being sent,
they all have the same content. this is stated in section 2.3:

'5. If the URI consists of a comma-separated list of recipients (i.e.,
contains multiple <sms-recipient> parts), all of them are processed in
this manner. Exactly the same message SHOULD be sent to all of the
listed recipients, which means that the message resulting from the
message composition step for the first recipient is used unaltered for
all other recipients as well.'

it seems to me that this is sufficiently clear, and the syntax as well
as the examples make it clear (it seems to me) that there can be more
than one recipient, and that an (optional) body can be supplied as the
initial message contents. do you think the whole draft is sort of
unclear at that, or just the abstract? the body part is not mentioned in
the abstract because it is optional, and because more often that not, it
will not be used.

cheers,

erik wilde   tel:[phone] - fax:[phone]
        dret@...  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

[Dan Brickley-2]

On Mon, Aug 24, 2009 at 7:33 PM, Erik Wilde<dret@...> wrote:

> hello dan.
>
> Dan Brickley wrote:
>>
>> Looking at the abstract and examples, the scope isn't very clear to me.
>> http://dret.net/netdret/docs/draft-wilde-sms-uri-19.html#uri-examples
>>  "for specifying one or more recipients for an SMS messages"
>> - grammar seems funny; "recipients for an SMS message" or "recipients
>> for SMS messages"
>
> i don't see where you copied that text, it seems to me there are two
> locations saying "one or more recipients for an SMS message", but i could
> not find the text you pasted here. maybe you looked at an older version?

I can't find it anywhere, and therefore must blush and admit I must
have introduced the error myself somehow while copy/pasting the text.
Apologies!

>> It might help if you list the classes of thing that this scheme
>> provides identifiers for? ie. an sms: URI could be an identifier for
>>  - a single sms-capable account
>>  - a list of sms-capable accounts
>>  - one or more accounts plus a draft message
>
> the difficulty may be that the intent of the scheme is to allow the sending
> of one message logically speaking, but since SMS does not have the
> capabilities to send one message to more than one recipient, on the SMS
> level this maps to a number of messages being sent, one to each individual
> recipient. since there are individual messages, they could be different, but
> the intent is that if multiple messages are being sent, they all have the
> same content. this is stated in section 2.3:
>
> '5. If the URI consists of a comma-separated list of recipients (i.e.,
> contains multiple <sms-recipient> parts), all of them are processed in this
> manner. Exactly the same message SHOULD be sent to all of the listed
> recipients, which means that the message resulting from the message
> composition step for the first recipient is used unaltered for all other
> recipients as well.'
>
> it seems to me that this is sufficiently clear, and the syntax as well as
> the examples make it clear (it seems to me) that there can be more than one
> recipient, and that an (optional) body can be supplied as the initial
> message contents. do you think the whole draft is sort of unclear at that,
> or just the abstract? the body part is not mentioned in the abstract because
> it is optional, and because more often that not, it will not be used.

I went in mainly via the abstract and examples, like 90% of your
readers will probably do. My main agenda when reading a new URI scheme
spec is to ask "ok, what kinds of thing does this spec let me
*identify*". So I tend to skip past the "verby" parts, ie. the actions
made possible. My understanding of the work of a URI scheme definition
(rather than a protocol that uses it) is that the thing that's being
standardised is a set of identifiers. So I am not completely sure how
action-related SHOULDs fit in. Did you consider making a separate
protocol for that? Would it make sense to separate out those aspects?

cheers,

Dan

[Erik Wilde-3]

hello dan.

> I went in mainly via the abstract and examples, like 90% of your
> readers will probably do. My main agenda when reading a new URI scheme
> spec is to ask "ok, what kinds of thing does this spec let me
> *identify*". So I tend to skip past the "verby" parts, ie. the actions
> made possible. My understanding of the work of a URI scheme definition
> (rather than a protocol that uses it) is that the thing that's being
> standardised is a set of identifiers. So I am not completely sure how
> action-related SHOULDs fit in. Did you consider making a separate
> protocol for that? Would it make sense to separate out those aspects?

identifiers with no associated actions are of limited use (not useless,
but in many cases, a lot of the value of URIs lies in the way how you
can interact with the identified resources using some well-known
mechanism; mailto: and tel: are the two examples most closely related to
the proposed scheme). i am not quite sure what you refer to by saying
"did you consider making a separate protocol for that"; the protocol i
am using (and not defining) is SMS, and the proposed URI scheme allows
clients to identify and support interactions with endpoints supporting
that protocol. in a mechanism that's not rather retrieval-oriented
(http:, for example, is mostly about that), but more focused on
interacting with a peer based on some addressing scheme and some
communications protocol, the most important thing is the action; the
fact that you can send a message to that endpoint.

i am pretty sure i am missing something here, and maybe it would help be
to better understand your concerns if you could make a concrete
suggestion of how you think the spec or some wording could be improved?

thanks and cheers,

erik wilde   tel:[phone] - fax:[phone]
        dret@...  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)