Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
From: Julian Reschke <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked], [email-masked]
Date: Sun, 30 Sep 2007 13:10:15 +0200
List-Id: Applications Review List <apps-review.ietf.org>

Hi,

thanks for the overview.

If that document indeed argues against new methods, for new URI schemes 
and for usage of WSDL it seems it needs to be either fixed or marked 
historic.

Maybe it's something for HTTPbis to look at?

Best regards, Julian

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sun, 30 Sep 2007 12:19:41 +0200
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
Cc: [email-masked], Chris Newman <[email-masked]>

Hi Lisa,
Hi Chris,
Hi all,

thank you Chris for the pointer to RFC 3205 (BCP 56). I now read it and 
it is indeed a very interesting document. Too bad that I didn't came 
across it earlier.
Reading through that document I got the impression that the suggestions 
that can be found in there are not exercised by today's protocol designs.

There are a couple of issues that require consideration when defining an 
HTTP transport:

(a) MIME-types. I believe we are doing fine with the usage of XML and 
the registration of a new mime type.

http://tools.ietf.org/html/draft-ietf-pkix-scvp-33 on the other hand 
uses different mime types for request and resonse messages. I don't 
think that this is necessary.

(b) No new HTTP method seems to be needed
(We don't do that in the DSKPP draft anyway)

(c) New port number for DSKPP since the usage is so different from 
ordinary HTTP webbrowsing
(This is quite controversal when it comes to firewall traversal and 
might require more discussions. See 
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00090.html)

None of the protocols I have been working on defines a new port. Can you 
give a reference to a recently developed protocol that carries XML on 
top of HTTP that uses a new port number?

(d) New URI scheme
(Currently we use the HTTP/HTTPS schemes but that does not seem to be 
inline with the recommendations in BCP 56.)

Neither HELD, SCVP, LoST nor DSKPP define a new URI scheme. In LoST we 
had a URL registration in the document once, see Section 16.5 of 
draft-ietf-ecrit-lost-03, but removed it later (co-author of that 
document is Ted Hardie, the former Applications Area Director).

(e) WSDL Usage: Lisa and Chris do not see WSDL as something being 
useful. In fact, I haven't found a person who argued in favor of WSDL. 
Hence, I believe we should avoid it.

(f) Error Codes: RFC 3205 points to the problems of defining error codes 
when applications are layered on top of HTTP. The suggestion is to 
essentially only use 200 (for complete success) and 500 (for complete 
failure) at the HTTP layer and to use "application" specific error codes 
inside the layer application itself. We are essentially doing this. The 
only other error message that is being mentioned is 403 and since it is 
independent of the DSKPP protocol interaction it should be fine as well.

(g) HTTP client, proxy and server code: We added text regarding the 
expected behavior of clients, proxies and server in Section 5 of 
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt. I 
guess we are doing fine there.

I am OK with (a), (b), (e), (f) and (g). I am not sure about (c) and 
(d). Help needed.

Ciao
Hannes

PS: Regarding Mime-Types:

In KEYPROV with the DSKPP document we should use application/dskpp+xml 
instead of application/vnd.ietf.keyprov.dskpp+xml

The IANA registry for the MIME type should look similar to the one in 
Section 17.2 of draft-ietf-ecrit-lost-06.

We also need to add a registry for the schema and the namespace (see 
Section 11.1 of draft-ietf-geopriv-http-location-delivery-02.txt for the 
URN sub-namespace registration, and Section 11.2 of for the XML schema 
registration).

Chris Newman wrote:
> I expect HTTP bindings to address the concerns raised in BCP 56.  
> Unless the primary client for your protocol is a web browser, I would 
> strongly encourage registering a separate port.  In the SMTP world, 
> the primary source of interoperability problems is application-level 
> gateways/firewalls.  At this point it's inevitable we'll end up with 
> intrusive firewalls on port 80 that will break anything beyond stock 
> browser-based HTTP.  I encourage new HTTP-based protocols to register 
> a separate port so they have the opportunity to avoid such damage and 
> interoperability problems.  It also simplifies responsible firewall 
> operation by enabling port-based service restrictions that are more 
> scalable and less intrusive.
>
> I have yet to see any evidence that WSDL is useful in practice but 
> that may be due to my lack of experience with web services.
>
> I find Relax NG and/or XML schema useful for XML-based 
> protocols/formats whether or not they are built on top of HTTP.  My 
> understanding is that Relax NG is better for extensible entity-based 
> XML formats, whereas XML Schema is better for XML formats with strong 
> value typing.
>
> I haven't reviewed the DSKPP draft yet.
>
>                - Chris
>
> Hannes Tschofenig wrote on 9/13/07 14:56 +0200:
>
>> Hi all,
>>
>> I would like to solicit feedback regarding the HTTP binding described in
>> DSKPP:
>> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt
>>
>> I went through a couple of documents that describe an HTTP binding and
>> noticed all of them are slightly different. If you, for example, take 
>> a look
>> at another recent work, namely HELD, from the GEOPRIV working group 
>> then you
>> will notice that the author incorporated a WSDL binding. The draft is 
>> here:
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery 
>>
>> -01.txt
>>
>> Do people on this list have an opinion about the content they would 
>> like to
>> see in these type of documents?
>> What is the opinion regarding the usage of WSDL?
>>
>> Ciao
>> Hannes
>
>
>
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/apps-review

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Thu, 27 Sep 2007 11:30:34 -0700
From: Chris Newman <[email-masked]>
To: Applications Area Review List <[email-masked]>
Subject: [APPS-REVIEW] Guidelines for protocol designers using UDP (fwd)

This document is likely to set the bar for use of UDP in application protocols. 
I'd like someone on apps-review to formally review this for me.  It would be 
especially helpful if that someone has implemented or specified UDP-based 
protocols in the past.

                Thanks,
                - Chris

---------- Forwarded Message ----------
Date: Thursday, September 27, 2007 13:33 +0200
From: Magnus Westerlund <[email-masked]>
To: Internet Area <[email-masked]>, [email-masked], 
[email-masked], [email-masked], SAAG <[email-masked]>
CC: tsvwg <[email-masked]>
Subject: Guidelines for protocol designers using UDP

Hi,

In the TSVWG we have been developing a guidelines document for UDP. It
is intended for protocol designers that consider using UDP in their
protocol. We do hope that it will help remove some of the misconception
that UDP is a simple protocol to use. It might look that way because
most of the features necessary for being acceptable to deploy on the
general internet needs to be specified by the one using UDP. It is also
something that the Transport ADs already started using as help in
explaining why and what to fix when we put a DISCUSS on your document
that is using UDP.

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-03.txt

So TSVWG is still working on this document but we are now considering it
quite complete. So we are looking for feedback from you. Are there
things that are unclear, missing, wrong, etc. Please provide your
feedback to TSVWG ([email-masked]).

Thanks

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---------- End Forwarded Message ----------

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sat, 22 Sep 2007 16:24:20 +0200
From: Hannes Tschofenig <[email-masked]>
To: Barry Leiba <[email-masked]>
Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
Cc: [email-masked]

Hi Barry,

Barry Leiba wrote:
>> I am not sure whether the separate port number idea will find a lot of
>> excitement since the downside is that a network operator that just 
>> does not
>> care about the specific protocol (even through he does not mind 
>> allowing end
>> hosts to run it) will essentially block it.
>
> Hannes, I'm not sure I understand what you're saying here, so maybe 
> you should explain more.  What I read it as saying is that you don't 
> like using a separate port because you *want* to sneak through 
> firewalls without telling the firewall administrators.  There be 
> dragons, and that was Chris's point.  A protocol that looks like HTTP 
> but is used for a different purpose should be on a different port.
>
> Actually, I've had this argument with people within my company too, 
> and it might be that we aren't clear about what the port-number list 
> *is*: it should be more like a list that maps *applications*, rather 
> than *protocols*, to ports.  In most cases, that's the same.  But with 
> SMTP and HTTP, at least, it's not.
>
I agree that it would be nice to allow administrators to make these type 
of decisions.

In other areas in the IETF folks also had the idea that the network 
administrators are going to configure their networks in such a way that 
the protocols would work. SIP and NAT/Firewall traversal is a good 
example. It took a while to realize that this is not a good approach.

DSKPP is an application layer protocols that allows an end point to 
retrieve keying material for usage with other protocols. Typically, the 
client on an end host will interact with a server in it's home network.
If I am in a hotel network and want to obtain new keying material for 
usage with my VPN client and the network administrator of the hotel 
network does not know the port number used by DSKPP then it might happen 
that I just cannot use the protocol.

Now, there are also other protocols flying around in this space; 
actually a large number of protocols in this identity management space 
that happen to run on top of HTTP without using an additional port (at 
least to my knowledge).

I don't see why these protocol should work in all environments (where 
HTTP traffic is allowed to bypass a middlebox) but a protocol developed 
within the IETF isn't just because there is this idea of a "clean 
architecture".

Does my reasoning make sense to you?

Ciao
Hannes

> Barry

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sat, 22 Sep 2007 10:10:52 -0400
From: Barry Leiba <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
Cc: [email-masked]

> I am not sure whether the separate port number idea will find a lot of
> excitement since the downside is that a network operator that just does not
> care about the specific protocol (even through he does not mind allowing end
> hosts to run it) will essentially block it.

Hannes, I'm not sure I understand what you're saying here, so maybe you should 
explain more.  What I read it as saying is that you don't like using a separate 
port because you *want* to sneak through firewalls without telling the firewall 
administrators.  There be dragons, and that was Chris's point.  A protocol that 
looks like HTTP but is used for a different purpose should be on a different port.

Actually, I've had this argument with people within my company too, and it might 
be that we aren't clear about what the port-number list *is*: it should be more 
like a list that maps *applications*, rather than *protocols*, to ports.  In most 
cases, that's the same.  But with SMTP and HTTP, at least, it's not.

Barry

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sat, 22 Sep 2007 15:14:28 +0200
From: Julian Reschke <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
Cc: Chris Newman <[email-masked]>, [email-masked]

Hannes Tschofenig wrote:
> ...
> I don't think that there is a difference between the two with this 
> respect. For protocols we don't put too many constraints on data types 
> in the schema anyway since there will not be any validation of incoming 
> messages since you have to parse them anyway.
> ...

That's what I thought as well.

> Relax NG vs. XML schema: We currently already have the XML schema in the 
> document and nobody in the group suggested to change it.
> When we picked a Relax NG schema for LoST (a different protocol) in the 
> ECRIT WG some folks did not like it due to the lack of available tools. 
> Programmers told us that they translated the Relax NG schema found in 
> the document into a XML schema. So, the Relax NG schema was not of great 
> value to them even though we thought it was much more convenient to use.

In WebDAV, we used DTD fragments to describe the formats (with the known 
shortcomings with respect to namespaces, element ordering and 
extensibility).

Replacing this with XML Schema would be IMHO a non-starter, because XML 
Schema has the same constraints with respect to extensibility as DTDs. 
Relax NG in its compact notation form looks very good, both because it's 
actually readable in a spec, and because it does all "we" (people 
working on WebDAV specs) need -- it works well with namespaces, and 
extensibility can actually be defined properly.

People who actually want to validate programmatically -- and in 
protocols it's not really clears that this is a good idea -- can either 
use the few Relax NG validators, or convert to XML Schema (or DTD) using 
Trang. And that's IMHO the biggest advantage: the RNC format is as 
readable as DTD, but it's better for defining protocol constraints than 
XNL Schema (1.0). And people who need XML Schema can still easily 
convert to it.

I think that's one of many things the AtomPub WG got right in RFC4287.

Best regards, Julian

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sat, 22 Sep 2007 14:45:05 +0200
From: Hannes Tschofenig <[email-masked]>
To: Julian Reschke <[email-masked]>
Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
Cc: Chris Newman <[email-masked]>, [email-masked]

Hi Julian,

Julian Reschke wrote:
> Hannes Tschofenig wrote:
>>> I find Relax NG and/or XML schema useful for XML-based 
>>> protocols/formats whether or not they are built on top of HTTP.  My 
>>> understanding is that Relax NG is better for extensible entity-based 
>>> XML formats, whereas XML Schema is better for XML formats with 
>>> strong value typing.
>> We will certainly make use of an XML schema.
> > ...
>
> Out of curiosity? How exactly is XML Schema superior with respect to 
> data typing?
>
I don't think that there is a difference between the two with this 
respect. For protocols we don't put too many constraints on data types 
in the schema anyway since there will not be any validation of incoming 
messages since you have to parse them anyway.

Relax NG vs. XML schema: We currently already have the XML schema in the 
document and nobody in the group suggested to change it.
When we picked a Relax NG schema for LoST (a different protocol) in the 
ECRIT WG some folks did not like it due to the lack of available tools. 
Programmers told us that they translated the Relax NG schema found in 
the document into a XML schema. So, the Relax NG schema was not of great 
value to them even though we thought it was much more convenient to use.

Ciao
Hannes

> Best regards, Julian
>
>
>
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/apps-review

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sat, 22 Sep 2007 12:09:13 +0200
From: Julian Reschke <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
Cc: Chris Newman <[email-masked]>, [email-masked]

Hannes Tschofenig wrote:
>> I find Relax NG and/or XML schema useful for XML-based 
>> protocols/formats whether or not they are built on top of HTTP.  My 
>> understanding is that Relax NG is better for extensible entity-based 
>> XML formats, whereas XML Schema is better for XML formats with strong 
>> value typing.
> We will certainly make use of an XML schema.
 > ...

Out of curiosity? How exactly is XML Schema superior with respect to 
data typing?

Best regards, Julian

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sat, 22 Sep 2007 11:40:42 +0200
From: Hannes Tschofenig <[email-masked]>
To: Chris Newman <[email-masked]>
Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
Cc: [email-masked]

Hi Chris,

thanks for the response.

Chris Newman wrote:

> I expect HTTP bindings to address the concerns raised in BCP 56.  

I will read through BCP 56.

> Unless the primary client for your protocol is a web browser, I would 
> strongly encourage registering a separate port.  In the SMTP world, 
> the primary source of interoperability problems is application-level 
> gateways/firewalls.  At this point it's inevitable we'll end up with 
> intrusive firewalls on port 80 that will break anything beyond stock 
> browser-based HTTP.  I encourage new HTTP-based protocols to register 
> a separate port so they have the opportunity to avoid such damage and 
> interoperability problems.  It also simplifies responsible firewall 
> operation by enabling port-based service restrictions that are more 
> scalable and less intrusive.
I am not sure whether the separate port number idea will find a lot of 
excitement since the downside is that a network operator that just does 
not care about the specific protocol (even through he does not mind 
allowing end hosts to run it) will essentially block it.

>
> I have yet to see any evidence that WSDL is useful in practice but 
> that may be due to my lack of experience with web services.
I have received this type of feedback from a couple of different sides 
already.

>
> I find Relax NG and/or XML schema useful for XML-based 
> protocols/formats whether or not they are built on top of HTTP.  My 
> understanding is that Relax NG is better for extensible entity-based 
> XML formats, whereas XML Schema is better for XML formats with strong 
> value typing.
We will certainly make use of an XML schema.

>
> I haven't reviewed the DSKPP draft yet.
>
I need to see whether I need to make changes based on the 
above-mentioned BCP. Hence, I would advice to wait a bit.

Ciao
Hannes

>                - Chris
>
> Hannes Tschofenig wrote on 9/13/07 14:56 +0200:
>
>> Hi all,
>>
>> I would like to solicit feedback regarding the HTTP binding described in
>> DSKPP:
>> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt
>>
>> I went through a couple of documents that describe an HTTP binding and
>> noticed all of them are slightly different. If you, for example, take 
>> a look
>> at another recent work, namely HELD, from the GEOPRIV working group 
>> then you
>> will notice that the author incorporated a WSDL binding. The draft is 
>> here:
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery 
>>
>> -01.txt
>>
>> Do people on this list have an opinion about the content they would 
>> like to
>> see in these type of documents?
>> What is the opinion regarding the usage of WSDL?
>>
>> Ciao
>> Hannes

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Fri, 21 Sep 2007 14:23:56 -0700
From: Chris Newman <[email-masked]>
Subject: Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP
To: Hannes Tschofenig <[email-masked]>, [email-masked]
Cc: 

I expect HTTP bindings to address the concerns raised in BCP 56.  Unless the 
primary client for your protocol is a web browser, I would strongly encourage 
registering a separate port.  In the SMTP world, the primary source of 
interoperability problems is application-level gateways/firewalls.  At this 
point it's inevitable we'll end up with intrusive firewalls on port 80 that 
will break anything beyond stock browser-based HTTP.  I encourage new 
HTTP-based protocols to register a separate port so they have the opportunity 
to avoid such damage and interoperability problems.  It also simplifies 
responsible firewall operation by enabling port-based service restrictions that 
are more scalable and less intrusive.

I have yet to see any evidence that WSDL is useful in practice but that may be 
due to my lack of experience with web services.

I find Relax NG and/or XML schema useful for XML-based protocols/formats 
whether or not they are built on top of HTTP.  My understanding is that Relax 
NG is better for extensible entity-based XML formats, whereas XML Schema is 
better for XML formats with strong value typing.

I haven't reviewed the DSKPP draft yet.

                - Chris

Hannes Tschofenig wrote on 9/13/07 14:56 +0200:

> Hi all,
>
> I would like to solicit feedback regarding the HTTP binding described in
> DSKPP:
> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt
>
> I went through a couple of documents that describe an HTTP binding and
> noticed all of them are slightly different. If you, for example, take a look
> at another recent work, namely HELD, from the GEOPRIV working group then you
> will notice that the author incorporated a WSDL binding. The draft is here:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery
> -01.txt
>
> Do people on this list have an opinion about the content they would like to
> see in these type of documents?
> What is the opinion regarding the usage of WSDL?
>
> Ciao
> Hannes

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Fri, 21 Sep 2007 13:09:32 +0200
From: Hannes Tschofenig <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: [APPS-REVIEW] Re: Review of HTTP Binding for DSKPP

Resend...

If you think that the DSKPP draft is fine (with respect to the HTTP 
binding) please also drop me a note.

Ciao
Hannes

Hannes Tschofenig wrote:
> Hi all,
>
> I would like to solicit feedback regarding the HTTP binding described 
> in DSKPP:
> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt
>
> I went through a couple of documents that describe an HTTP binding and 
> noticed all of them are slightly different. If you, for example, take 
> a look at another recent work, namely HELD, from the GEOPRIV working 
> group then you will notice that the author incorporated a WSDL 
> binding. The draft is here:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt 
>
>
> Do people on this list have an opinion about the content they would 
> like to see in these type of documents?
> What is the opinion regarding the usage of WSDL?
>
> Ciao
> Hannes
>
>
>
>

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sun, 16 Sep 2007 11:14:32 +0200
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: 
Subject: [APPS-REVIEW] Review of HTTP Binding for DSKPP

Hi all,

I would like to solicit feedback regarding the HTTP binding described in 
DSKPP:
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt

I went through a couple of documents that describe an HTTP binding and 
noticed all of them are slightly different. If you, for example, take a 
look at another recent work, namely HELD, from the GEOPRIV working group 
then you will notice that the author incorporated a WSDL binding. The 
draft is here:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt 

Do people on this list have an opinion about the content they would like 
to see in these type of documents?
What is the opinion regarding the usage of WSDL?

Ciao
Hannes

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Thu, 13 Sep 2007 14:56:54 +0200
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: 
Subject: [APPS-REVIEW] Review of HTTP Binding for DSKPP

Hi all,

I would like to solicit feedback regarding the HTTP binding described in 
DSKPP:
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt

I went through a couple of documents that describe an HTTP binding and 
noticed all of them are slightly different. If you, for example, take a 
look at another recent work, namely HELD, from the GEOPRIV working group 
then you will notice that the author incorporated a WSDL binding. The 
draft is here:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt 

Do people on this list have an opinion about the content they would like 
to see in these type of documents?
What is the opinion regarding the usage of WSDL?

Ciao
Hannes

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Mon, 3 Sep 2007 14:19:37 +0200 (CEST)
From: Claudio Allocchio <[email-masked]>
To: Larry Masinter <[email-masked]>
Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question
Cc: [email-masked], Larry Masinter <[email-masked]>, Paul Hoffman <[email-masked]>, Martin Duerst <[email-masked]>, [email-masked]

On Sun, 2 Sep 2007, Larry Masinter wrote:

> I think when we revised the uri scheme registration rules, we gave up on 
> the idea (most likely W3C policy) of trying to discourage URI schemes 
> with narrow applicability by limiting registration, because the result 
> was widespread use of unregistered schemes. And SMS is different enough 
> from email to not fit nicely into mailto.

True, and this was agreed also by the draft editors during the quite long 
discussion which wa suseful to prepare the current draft.

>So I have no doubt that it 
> should be registered, and just would focus on ensuring that the 
> definition is clear enough that the players know what to do -- and not 
> to mandate behavior that is unlikely to be implemented.

I fully agree.

> There are several players, including those who write software that 
> interprets URIs to send SMS messages (handset protocol stack), or 
> construct URIs from parameters (browsers) or supply those parameters 
> (html forms) or the URIs themselves.
>
> Is the supplier of a URI (or a form with a SMS target) expected to be 
> aware of the nature of URI-interpreter's handling of long SMS messages? 
> (I can see how they might know about the SMS receiver since they supply 
> the number.)

I think the answer is YES. Has the "long SMS" handling is quite odd, 
implementers should take care of its possible effects (for example strings 
being cut into separate SMS messages!).

> I think it comes down to whether you require the SMS-sender to always 
> use the long-message standard (even if the lower level stack doesn't). 
> If not, then it would be convenient to warn html form authors that sms 
> messages longer than the single message length limit might not be sent 
> interoperably.

Also true. 
>
>
>
> -----Original Message-----
> From: 	Thomas Roessler [mailto:[email-masked]]
> Sent:	Sunday, September 02, 2007 06:12 AM Pacific Standard Time
> To:	Lisa Dusseault
> Cc:	[email-masked]; Martin Duerst; Larry Masinter; [email-masked]; Paul Hoffman
> Subject:	Re: [APPS-REVIEW] Fwd: SMS URI spec question
>
> On 2007-08-31 08:47:28 -0700, Lisa Dusseault wrote:
>
>> http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt
>>
>> has a bunch of URL parameters which are instructions not only to
>> the agent originating the SMS message (similar to the subject in
>> mailto:[email-masked];subject=HelloWorld ) but also instructions
>> to the SMSC (SMS Center).  Some features even instruct the SMSC
>> to send multiple messages, or gateway to a different protocol, or
>> both.
>
> Looking through the specification, there seems to be an
> architectural decision in here to conflate the use of SMS facilities
> to send text messages (for which a separate SMS URI scheme would
> indeed seem very useful) with the use of these facilities as
> infrastructure to do other things for which more or less
> transport-independent URI schemes have already been defined.
>
> For these latter use case, having an infrastructure-specific URI
> scheme is worrying.
>
> Specifically, I've got some questions about the relation of this
> specification to the tel:, fax:, mailto: URI schemes.
>
> Starting with e-mail, the example in 2.4 has a phone number that's
> (apparently) not used, which suggests that something might be wrong
> with the proposed URL syntax in the first place.
>
> More importantly, however, what's the rationale why a mailto URL
> couldn't be used for the precise same use case?  Re-reading RFC
> 2368, I don't see any reason why a "mailto:" URI couldn't be
> "dereferenced" by sending specially crafted SMSes that cause the
> SMSC to produce and send the corresponding e-mail message.  On the
> other hand, taking a form submission use case, it would seem like a
> local policy decision on the user-agent side whether an e-mail to an
> Internet mailbox is gatewayed through SMS or sent through SMTP
> directly (or maybe through avian carriers).
>
> Similarly, what's the rationale why the fax URI scheme (which comes
> with an extension mechanism) couldn't be used to specify message
> content along with a fax-ness of the recipient's number, without
> ever using an SMS URI?
>
> Similarly, what's the rationale why the voice services can't be
> handled by the same approach?
>
> I would also like to understand the rationale for specifying SMSCs
> as part of the URI in more detail.  At best, this is a
> layer-violating fix for SMS-related routing issues.  At worst, we're
> just specifying mobile network specific URIs for classical Internet
> services which can conveniently be tied to a particular network
> operator.  Which would be worrying.
>
> As Larry already pointed out, section 3 feels out of place, as it
> seems to specify implementation details for a particular type of URI
> handler.  If this section remains part of the document, however, it
> might also be useful to say a word or two about safe and unsafe HTTP
> methods.  You really don't want to trigger an SMS with a GET.
>
> Regards,
> -- 
> Thomas Roessler, W3C  <[email-masked]>  +33-4-89063488
>
>
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/apps-review
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Content-class: urn:content-classes:message
Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question
Date: Sun, 2 Sep 2007 12:22:56 -0700
From: "Larry Masinter" <[email-masked]>
To: "Thomas Roessler" <[email-masked]>, "Lisa Dusseault" <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, Martin Duerst <[email-masked]>, [email-masked], Larry Masinter <[email-masked]>, [email-masked]

I think when we revised the uri scheme registration rules, we gave up on =
the idea (most likely W3C policy) of trying to discourage URI schemes =
with narrow applicability by limiting registration, because the result =
was widespread use of unregistered schemes. And SMS is different enough =
from email to not fit nicely into mailto. So I have no doubt that it =
should be registered, and just would focus on ensuring that the =
definition is clear enough that the players know what to do -- and not =
to mandate behavior that is unlikely to be implemented.

There are several players, including those who write software that =
interprets URIs to send SMS messages (handset protocol stack), or =
construct URIs from parameters (browsers) or supply those parameters =
(html forms) or the URIs themselves.

Is the supplier of a URI (or a form with a SMS target) expected to be =
aware of the nature of URI-interpreter's handling of long SMS messages?  =
(I can see how they might know about the SMS receiver since they supply =
the number.)
   =20
I think it comes down to whether you require the SMS-sender to always =
use the long-message standard (even if the lower level stack doesn't). =
If not, then it would be convenient to warn html form authors that sms =
messages longer than the single message length limit might not be sent =
interoperably.

 -----Original Message-----
From: 	Thomas Roessler [mailto:[email-masked]]
Sent:	Sunday, September 02, 2007 06:12 AM Pacific Standard Time
To:	Lisa Dusseault
Cc:	[email-masked]; Martin Duerst; Larry Masinter; [email-masked]; =
Paul Hoffman
Subject:	Re: [APPS-REVIEW] Fwd: SMS URI spec question

On 2007-08-31 08:47:28 -0700, Lisa Dusseault wrote:

> http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt
>
> has a bunch of URL parameters which are instructions not only to
> the agent originating the SMS message (similar to the subject in=20
> mailto:[email-masked];subject=3DHelloWorld ) but also instructions
> to the SMSC (SMS Center).  Some features even instruct the SMSC
> to send multiple messages, or gateway to a different protocol, or
> both.

Looking through the specification, there seems to be an
architectural decision in here to conflate the use of SMS facilities
to send text messages (for which a separate SMS URI scheme would
indeed seem very useful) with the use of these facilities as
infrastructure to do other things for which more or less
transport-independent URI schemes have already been defined.=20

For these latter use case, having an infrastructure-specific URI
scheme is worrying.

Specifically, I've got some questions about the relation of this
specification to the tel:, fax:, mailto: URI schemes.

Starting with e-mail, the example in 2.4 has a phone number that's
(apparently) not used, which suggests that something might be wrong
with the proposed URL syntax in the first place.

More importantly, however, what's the rationale why a mailto URL
couldn't be used for the precise same use case?  Re-reading RFC
2368, I don't see any reason why a "mailto:" URI couldn't be
"dereferenced" by sending specially crafted SMSes that cause the
SMSC to produce and send the corresponding e-mail message.  On the
other hand, taking a form submission use case, it would seem like a
local policy decision on the user-agent side whether an e-mail to an
Internet mailbox is gatewayed through SMS or sent through SMTP
directly (or maybe through avian carriers).

Similarly, what's the rationale why the fax URI scheme (which comes
with an extension mechanism) couldn't be used to specify message
content along with a fax-ness of the recipient's number, without
ever using an SMS URI?

Similarly, what's the rationale why the voice services can't be
handled by the same approach?

I would also like to understand the rationale for specifying SMSCs
as part of the URI in more detail.  At best, this is a
layer-violating fix for SMS-related routing issues.  At worst, we're
just specifying mobile network specific URIs for classical Internet
services which can conveniently be tied to a particular network
operator.  Which would be worrying.

As Larry already pointed out, section 3 feels out of place, as it
seems to specify implementation details for a particular type of URI
handler.  If this section remains part of the document, however, it
might also be useful to say a word or two about safe and unsafe HTTP
methods.  You really don't want to trigger an SMS with a GET.

Regards,
--=20
Thomas Roessler, W3C  <[email-masked]>  +33-4-89063488

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Mon, 3 Sep 2007 09:49:51 +0200
From: Thomas Roessler <[email-masked]>
To: Larry Masinter <[email-masked]>
Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question
Mail-Followup-To: Larry Masinter <[email-masked]>, Lisa Dusseault <[email-masked]>, [email-masked], Martin Duerst <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Cc: [email-masked], Larry Masinter <[email-masked]>, Paul Hoffman <[email-masked]>, Martin Duerst <[email-masked]>, [email-masked]

On 2007-09-02 12:22:56 -0700, Larry Masinter wrote:

> I think when we revised the uri scheme registration rules, we
> gave up on the idea (most likely W3C policy) of trying to
> discourage URI schemes with narrow applicability by limiting
> registration, because the result was widespread use of
> unregistered schemes. And SMS is different enough from email to
> not fit nicely into mailto.

Umh...  I must have been unclear.  I'm *not* suggesting that "sms"
be replaced by "mailto", or that the scheme be rejected.

However, I am suggesting that "SMS to be turned into Internet e-mail
message at SMSC" is maybe better dealt with by a mailto URI;
likewise for the "text-to-voice" and "text-to-fax" gateway
functionalities and the tel and fax URI schemes.

Regards,
-- 
Thomas Roessler, W3C  <[email-masked]>  +33-4-89063488

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sun, 2 Sep 2007 15:12:27 +0200
From: Thomas Roessler <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question
Mail-Followup-To: Lisa Dusseault <[email-masked]>, [email-masked], Martin Duerst <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, Martin Duerst <[email-masked]>, [email-masked], Larry Masinter <[email-masked]>, [email-masked]

On 2007-08-31 08:47:28 -0700, Lisa Dusseault wrote:

> http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt
>
> has a bunch of URL parameters which are instructions not only to
> the agent originating the SMS message (similar to the subject in 
> mailto:[email-masked];subject=HelloWorld ) but also instructions
> to the SMSC (SMS Center).  Some features even instruct the SMSC
> to send multiple messages, or gateway to a different protocol, or
> both.

Looking through the specification, there seems to be an
architectural decision in here to conflate the use of SMS facilities
to send text messages (for which a separate SMS URI scheme would
indeed seem very useful) with the use of these facilities as
infrastructure to do other things for which more or less
transport-independent URI schemes have already been defined. 

For these latter use case, having an infrastructure-specific URI
scheme is worrying.

Specifically, I've got some questions about the relation of this
specification to the tel:, fax:, mailto: URI schemes.

Starting with e-mail, the example in 2.4 has a phone number that's
(apparently) not used, which suggests that something might be wrong
with the proposed URL syntax in the first place.

More importantly, however, what's the rationale why a mailto URL
couldn't be used for the precise same use case?  Re-reading RFC
2368, I don't see any reason why a "mailto:" URI couldn't be
"dereferenced" by sending specially crafted SMSes that cause the
SMSC to produce and send the corresponding e-mail message.  On the
other hand, taking a form submission use case, it would seem like a
local policy decision on the user-agent side whether an e-mail to an
Internet mailbox is gatewayed through SMS or sent through SMTP
directly (or maybe through avian carriers).

Similarly, what's the rationale why the fax URI scheme (which comes
with an extension mechanism) couldn't be used to specify message
content along with a fax-ness of the recipient's number, without
ever using an SMS URI?

Similarly, what's the rationale why the voice services can't be
handled by the same approach?

I would also like to understand the rationale for specifying SMSCs
as part of the URI in more detail.  At best, this is a
layer-violating fix for SMS-related routing issues.  At worst, we're
just specifying mobile network specific URIs for classical Internet
services which can conveniently be tied to a particular network
operator.  Which would be worrying.

As Larry already pointed out, section 3 feels out of place, as it
seems to specify implementation details for a particular type of URI
handler.  If this section remains part of the document, however, it
might also be useful to say a word or two about safe and unsafe HTTP
methods.  You really don't want to trigger an SMS with a GET.

Regards,
-- 
Thomas Roessler, W3C  <[email-masked]>  +33-4-89063488

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Fri, 31 Aug 2007 08:56:47 -0700
To: Lisa Dusseault <[email-masked]>, [email-masked], Martin Duerst <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Cc: 
Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question

At 8:47 AM -0700 8/31/07, Lisa Dusseault wrote:
>The SMS URI draft:
>
><http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt>http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt
>
>has a bunch of URL parameters which are instructions not only to the 
>agent originating the SMS message (similar to the subject in 
><mailto:[email-masked]>mailto:[email-masked];subject=HelloWorld ) 
>but also instructions to the SMSC (SMS Center).   Some features even 
>instruct the SMSC to send multiple messages, or gateway to a 
>different protocol, or both.
>
>I'm hoping that Apps reviewers plus mailto schema experts can either 
>quell my qualms or inform them.  Any thoughts?

We have had no problems with mailto: and headers that I know of. The 
only complaint I ever hear is that it doesn't handle MIME messages.

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sat, 1 Sep 2007 18:25:15 -0700
From: "Larry Masinter" <[email-masked]>
To: "Erik Wilde" <[email-masked]>
Cc: [email-masked], [email-masked], Paul Hoffman <[email-masked]>, Martin Duerst <[email-masked]>, [email-masked]
Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question

> > I'm uncomfortable with the vague way in which "SMS messages can
> > be concatenated to form longer messages" and the length limit,
> > especially since you're expecting clients to dynamically generate
> > sms messages for things like form submission. I think you either
> > need to define the length limit and how it applies, or else define
> > how, given a sms URI with a really long message body, how to turn
> > it into a sequence of sms messages.
>
> on the technical side, there are various ways how to encode a longer
> message as a sequence of sms messages, and for example, various device
> manufacturers of mobile phones choose various ways of doing this. there
> is no technical limit to the number of messages that can be
> concatenated, and the main concern is more about cost, because in a
> typical environment, users are charged for each sms message.

How does the sender of a long message know how to split up the message
so that the receiver will properly interpret it? Can they ever be
delivered out of order? Are the messages numbered?  Is there an
agreed-upon maximum length?

Do you need private out-of-band information to reconstruct the
original intended message from the sequence of SMS messages?

You're going out of your way to specify transmission parameters for
most other SMS capabilities, I'm not understanding how this part is
interoperable.

Larry

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Sat, 01 Sep 2007 22:51:21 -0700
From: Erik Wilde <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], Paul Hoffman <[email-masked]>, Martin Duerst <[email-masked]>, [email-masked]
Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question

hello larry.

>> on the technical side, there are various ways how to encode a longer
>> message as a sequence of sms messages, and for example, various device
>> manufacturers of mobile phones choose various ways of doing this. there
>> is no technical limit to the number of messages that can be
>> concatenated, and the main concern is more about cost, because in a
>> typical environment, users are charged for each sms message.
> How does the sender of a long message know how to split up the message
> so that the receiver will properly interpret it? Can they ever be
> delivered out of order? Are the messages numbered?  Is there an
> agreed-upon maximum length?

section 9.2.3.24.1 of 
http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/23040-701.zip 
(the current sms spec) contains the details about concatenated sms 
messages. there is a standard format how to transmit them, but not all 
client use this, some use their own, in which case it is impossible to 
say anything about their constraints. if senders use the standard 
format, the following rules apply:

- the sender assumes that the recipient understands the concatenated 
format. if the recipient does not understand it (such as the stupid 
iphone), the messages appear as individual messages with weird control 
characters in them.

- delivery of sms messages in not ordered, but if the standard mechanism 
is used, messages can be reordered on the recipient side. if the sender 
or the recipient do not support the standard format, messages may appear 
out of order.

- the standard format has a numbering scheme, which is used for ordering 
the messages: "Each concatenated short message contains a reference 
number which together with the originating address and Service Centre 
address allows the receiving entity to discriminate between concatenated 
short messages sent from different originating SMEs and/or SCs."

- the standard states: "The maximum length of an uncompressed 
concatenated short message is 39015 (255*153) default alphabet 
characters, 34170 (255*134) octets or 17085 (255*67) UCS2 characters.
The maximum length of a compressed concatenated message is 34170 
(255*134) octets including the Compression Header and Compression Footer 
(see clause 3.9 and figure 9.2.3.24.1(a) below)." my guess is that most 
recipients (typically mobile phones) will implement smaller limits, but 
i have no facts about that. antti may have some details here.

> Do you need private out-of-band information to reconstruct the
> original intended message from the sequence of SMS messages?

no, the standard format has everything that is required to make things work.

> You're going out of your way to specify transmission parameters for
> most other SMS capabilities, I'm not understanding how this part is
> interoperable.

i do understand your point that we are talking about the "maximum SMS 
message size", and then not say anything about it. would your comment be 
addressed by adding a sentence quoting the maximum size defined by the 
standard or the maximum size supported by the sender, and using whatever 
is the smaller number?

thanks and cheers,

dret.

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Fri, 31 Aug 2007 11:22:11 -0700
From: Erik Wilde <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], 'Paul Hoffman' <[email-masked]>, 'Martin Duerst' <[email-masked]>, [email-masked]
Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question

hello everybody.

thanks for the feedback, i will try to address all the questions and 
will integrate these changes into a new version of the draft, which 
hopefully can be published very soon.

> Is there a registry of pid-value, or is this it? Isn't it likely
> that most of the values will be unimplemented? I suppose it's harmless.

the "registry" is in the sms spec, i updated the sms spec reference to 
point to the latest version, and 
http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/23040-701.zip 
section "9.2.3.9 TP Protocol Identifier (TP PID)" is where the 
identifiers are listed. it is pretty much a closed list, because it is 
based on bit patterns and there are only few left... and yes, most of 
these probably will not be implemented, but since they are part of the 
spec, they could be implemented.

> I'm uncomfortable with the vague way in which "SMS messages can
> be concatenated to form longer messages" and the length limit,
> especially since you're expecting clients to dynamically generate
> sms messages for things like form submission. I think you either
> need to define the length limit and how it applies, or else define
> how, given a sms URI with a really long message body, how to turn
> it into a sequence of sms messages.

on the technical side, there are various ways how to encode a longer 
message as a sequence of sms messages, and for example, various device 
manufacturers of mobile phones choose various ways of doing this. there 
is no technical limit to the number of messages that can be 
concatenated, and the main concern is more about cost, because in a 
typical environment, users are charged for each sms message.

sadly, some devices do not give any reasonable feedback about the number 
of messages they are generating, the iphone for example supports sms 
messaging, but does not show you how many messages you will produce (and 
have to pay for). skype, on the other hand, faithfully shows to how many 
sms messages your longer message will be mapped.

so i don't see a reasonable way to limit the length, but maybe it would 
be appropriate to say that a client SHOULD make the user aware of the 
number of messages that will be sent? would that address your concerns?

> Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references
> "just as they are packaged when using a "mailto" URI, but the definition of
> how
> that happens is a feature of HTML and not of the URI scheme.
> My recollection is that it isn't formally defined in the
> W3C HTML specification, but it's also not in any (not obsolete)
> IETF document. Same problem for web services. Perhaps those sections
> should be marked as non-normative, and instead become informational  --
> how the authors or their organizations intend to propose the
> described changes to the appropriate standards bodies for the
> relevant specifications.

i have the same recollection as you, that there is no formal standard 
about this anywhere. how would be go about marking these as informal? is 
there a formal way of doing this, or just add a sentence at the 
beggining saying "the text of the following subsection is informal and 
for informational purposes only"?

> I don't know why they need to specify section 3 at all -- every
> web service SMS gateway could define its own mechanism for sending
> SMS without making up funny URIs as a way of carrying the
> destination information. Is this just an example? 

this section probably is a result of my personal frustration with how 
badly most clients handle unknown uri schemes, and that a more 
systematic way of doing this would be a good idea. would it be ok to 
leave it in there and mark it as informal as well? if not, i can remove it.

> 4.4: of course it addresses a resource. That's why they're defining
> a Resource Identifier. I'd just delete the first two sentences
> and the "Instead, ". 

ok, done.

thanks a lot and kind regards,

dret.

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

From: "Larry Masinter" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Lisa Dusseault'" <[email-masked]>, <[email-masked]>, "'Martin Duerst'" <[email-masked]>, <[email-masked]>
Date: Fri, 31 Aug 2007 10:50:58 -0700
Cc: [email-masked], [email-masked]
Subject: [APPS-REVIEW] RE: Fwd: SMS URI spec question

Is there a registry of pid-value, or is this it? Isn't it likely
that most of the values will be unimplemented? I suppose it's harmless.

I'm uncomfortable with the vague way in which "SMS messages can
be concatenated to form longer messages" and the length limit,
especially since you're expecting clients to dynamically generate
sms messages for things like form submission. I think you either
need to define the length limit and how it applies, or else define
how, given a sms URI with a really long message body, how to turn
it into a sequence of sms messages.

Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references
"just as they are packaged when using a "mailto" URI, but the definition of
how
that happens is a feature of HTML and not of the URI scheme.
My recollection is that it isn't formally defined in the
W3C HTML specification, but it's also not in any (not obsolete)
IETF document. Same problem for web services. Perhaps those sections
should be marked as non-normative, and instead become informational  --
how the authors or their organizations intend to propose the
described changes to the appropriate standards bodies for the
relevant specifications.

I don't know why they need to specify section 3 at all -- every
web service SMS gateway could define its own mechanism for sending
SMS without making up funny URIs as a way of carrying the
destination information. Is this just an example? 

4.4: of course it addresses a resource. That's why they're defining
a Resource Identifier. I'd just delete the first two sentences
and the "Instead, ". 

Larry

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Fri, 31 Aug 2007 11:22:11 -0700
From: Erik Wilde <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], 'Paul Hoffman' <[email-masked]>, 'Martin Duerst' <[email-masked]>, [email-masked]
Subject: [APPS-REVIEW] Re: Fwd: SMS URI spec question

hello everybody.

thanks for the feedback, i will try to address all the questions and 
will integrate these changes into a new version of the draft, which 
hopefully can be published very soon.

> Is there a registry of pid-value, or is this it? Isn't it likely
> that most of the values will be unimplemented? I suppose it's harmless.

the "registry" is in the sms spec, i updated the sms spec reference to 
point to the latest version, and 
http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/23040-701.zip 
section "9.2.3.9 TP Protocol Identifier (TP PID)" is where the 
identifiers are listed. it is pretty much a closed list, because it is 
based on bit patterns and there are only few left... and yes, most of 
these probably will not be implemented, but since they are part of the 
spec, they could be implemented.

> I'm uncomfortable with the vague way in which "SMS messages can
> be concatenated to form longer messages" and the length limit,
> especially since you're expecting clients to dynamically generate
> sms messages for things like form submission. I think you either
> need to define the length limit and how it applies, or else define
> how, given a sms URI with a really long message body, how to turn
> it into a sequence of sms messages.

on the technical side, there are various ways how to encode a longer 
message as a sequence of sms messages, and for example, various device 
manufacturers of mobile phones choose various ways of doing this. there 
is no technical limit to the number of messages that can be 
concatenated, and the main concern is more about cost, because in a 
typical environment, users are charged for each sms message.

sadly, some devices do not give any reasonable feedback about the number 
of messages they are generating, the iphone for example supports sms 
messaging, but does not show you how many messages you will produce (and 
have to pay for). skype, on the other hand, faithfully shows to how many 
sms messages your longer message will be mapped.

so i don't see a reasonable way to limit the length, but maybe it would 
be appropriate to say that a client SHOULD make the user aware of the 
number of messages that will be sent? would that address your concerns?

> Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references
> "just as they are packaged when using a "mailto" URI, but the definition of
> how
> that happens is a feature of HTML and not of the URI scheme.
> My recollection is that it isn't formally defined in the
> W3C HTML specification, but it's also not in any (not obsolete)
> IETF document. Same problem for web services. Perhaps those sections
> should be marked as non-normative, and instead become informational  --
> how the authors or their organizations intend to propose the
> described changes to the appropriate standards bodies for the
> relevant specifications.

i have the same recollection as you, that there is no formal standard 
about this anywhere. how would be go about marking these as informal? is 
there a formal way of doing this, or just add a sentence at the 
beggining saying "the text of the following subsection is informal and 
for informational purposes only"?

> I don't know why they need to specify section 3 at all -- every
> web service SMS gateway could define its own mechanism for sending
> SMS without making up funny URIs as a way of carrying the
> destination information. Is this just an example? 

this section probably is a result of my personal frustration with how 
badly most clients handle unknown uri schemes, and that a more 
systematic way of doing this would be a good idea. would it be ok to 
leave it in there and mark it as informal as well? if not, i can remove it.

> 4.4: of course it addresses a resource. That's why they're defining
> a Resource Identifier. I'd just delete the first two sentences
> and the "Instead, ". 

ok, done.

thanks a lot and kind regards,

dret.

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

From: "Larry Masinter" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Lisa Dusseault'" <[email-masked]>, <[email-masked]>, "'Martin Duerst'" <[email-masked]>, <[email-masked]>
Date: Fri, 31 Aug 2007 10:50:58 -0700
Cc: [email-masked], [email-masked]
Subject: [APPS-REVIEW] RE: Fwd: SMS URI spec question

Is there a registry of pid-value, or is this it? Isn't it likely
that most of the values will be unimplemented? I suppose it's harmless.

I'm uncomfortable with the vague way in which "SMS messages can
be concatenated to form longer messages" and the length limit,
especially since you're expecting clients to dynamically generate
sms messages for things like form submission. I think you either
need to define the length limit and how it applies, or else define
how, given a sms URI with a really long message body, how to turn
it into a sequence of sms messages.

Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references
"just as they are packaged when using a "mailto" URI, but the definition of
how
that happens is a feature of HTML and not of the URI scheme.
My recollection is that it isn't formally defined in the
W3C HTML specification, but it's also not in any (not obsolete)
IETF document. Same problem for web services. Perhaps those sections
should be marked as non-normative, and instead become informational  --
how the authors or their organizations intend to propose the
described changes to the appropriate standards bodies for the
relevant specifications.

I don't know why they need to specify section 3 at all -- every
web service SMS gateway could define its own mechanism for sending
SMS without making up funny URIs as a way of carrying the
destination information. Is this just an example? 

4.4: of course it addresses a resource. That's why they're defining
a Resource Identifier. I'd just delete the first two sentences
and the "Instead, ". 

Larry

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review